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Foreword 


aster data management (MDM) is a strategic, competi- 

tive business strategy. Is your business looking for 
new ways to drive down costs or enable better regulatory 
compliance? What about enabling growth as the economic 
upturn comes or when M&A (mergers and acquisitions) are 
on the horizon? Whether increasing revenue, improving risk 
management and compliance, optimizing operational efficien- 
cies, or strategically differentiating an organization from its 
competitors, MDM is widely recognized at the executive level 
as a compelling proposition. It’s usually manifested in a stra- 
tegic business initiative called a single view of the customer or 
some similar name. 


Here are some things to keep in mind about MDM: 


~~ MDM is pandemic. MDM provides a trusted, consistent 
view of key information assets across the enterprise — 
ranging from customers, products, and suppliers to 
locations and more. In large corporations, MDM is 
increasingly becoming a business transformation 
strategy as the cornerstone of every critical business 
process and business decision. 


MDM as “career insurance/diversification.” Face it, 
MDM is coming to an IT organization near you. Savvy IT 
professionals in the business intelligence and application 
integration fields are revamping their skills, portfolio, 
and resumes to focus on MDM as a key opportunity. The 
job titles that are the primary beneficiaries of the current 
shortage in MDM expertise are: enterprise data/solu- 
tion architects, enterprise data modelers, MDM program 
leads, directors of data governance, and data stewards. 
Now is the opportune time to update your IT skills port- 
folio to leverage such key trends. 


Looking for the straight facts on MDM? In this 
friendly, authoritative guide, renowned MDM and BPM 
practitioners Alexander Hoeppe, Mathew Manathara, and 
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Jignesh Shah provide the reader the latest on everything 
from data governance and reference data to new MDM 
methods such as big data and cloud-enablement. 

They also debunk technical myths and cover new 
methodologies to overcome business dysfunction and 
organizational entropy as well as enhance profitability, 
increase customer satisfaction, and enable a more agile 
organization that is M&A-ready and channel-flexible for 
the brave new worlds of IT yet to come. That’s a lot of 
territory for one book to cover! Lastly, for anyone who’s 
ever been frustrated by vendor “market-tectures” and 
dogma or industry analyst pedantic models, this guide 
explains a wide range of use cases and best practices 
using common sense analogies and terminology. 


The bottom line is that MDM is quickly broadening its attrac- 
tiveness as a key enabler of strategic business initiatives as 
well as tactical P&L initiatives. As of 2011, MDM is clearly for 
the masses as well as business-critical for large enterprises. 
And both MDM and BPM professionals need to do more than 
just get along. Now is the perfect time for this book, which 
brings the two worlds together in clear focus in an informa- 
tive style that everyone can benefit from — whether you area 
data person (MDM architects), a process engineer (BPM mod- 
elers), or someone interested in seeing how MDM can help 
their business. 


Aaron Zornes 

Chief Research Officer, The MDM Institute 
Conference Chairman, 

The MDM & Data Governance Summit Series 
(London, New York City, San Francisco, 
Singapore, Sydney, Tokyo, Toronto) 
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Introduction 







our business runs on data and processes. Whether you 
realize it or not, almost every process operating in your 
business is creating, changing, or using data. As processes 
and enterprises grow larger and more complex, there’s an 
inevitable tendency for master data, those critical pieces of 
information that you must get right, to become duplicative 
and inaccurate. When this occurs, you have a master data 
problem that will have a negative impact on your business. 


Not all data in your business is master data. Master data is 
data that is essential for the correct completion of core busi- 
ness processes. Customer names and addresses, for example, 
constitute master data, as do product SKUs. Problems with 
master data can lead to serious business problems that 
include excessive customer service costs, reputation damage, 
and even legal liability. 


Master data management (MDM) is the discipline of assuring 
that master data elements are correct and consistent across 
the organization. Our perspective on MDM, however, is some- 
what different from the norm. Many organizations approach 
MDM from a wholly IT perspective focused on improving the 
quality of data. In our experience, MDM is really much more 
of a business issue. MDM is about more than just cleaning up 
databases. MDM is about making your business processes (and 
your overall business) run as well as they can. In our view, 
MDM should be owned by business stakeholders and incorpo- 
rate business processes. We call this process-driven MDM. 


Process-driven MDM attacks master data problems from a 
business perspective. It seeks business objectives and defini- 
tions of success for what can otherwise be an esoteric IT 
exercise. Process-driven MDM makes master data a business 
issue and unites IT and business managers in realizing the 
goal of high quality master data in business processes. 
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About This Book 


We wrote this book to introduce you to the subject of process- 
driven MDM. It’s a big topic, one that far outstrips the ability of 
a brief book to cover. However, our hope is that by reading this 
book you will gain a fundamental understanding of process- 
driven MDM, how it works, and what it takes to make it a suc- 
cess in your organization. 


Our assumption is that you have either a role in IT ora 
business-facing position that makes you interested in busi- 
ness process management and optimization. We also assume 
that you have some basic familiarity with IT systems and 
databases, as well as business processes and operational con- 
cepts. We don’t delve too deeply into either topic in this book, 
but we do use some language that relates to both the business 
and IT sides of the MDM discipline. 


This book relates to anumber of other publications we have 
created to discuss the role of business processes and service- 
oriented architecture (SOA) in the corporate context. To 
become a smarty on these topics, we suggest you look at BPM 
Basics For Dummies by Kiran Garimella, Mike Lees, and Bruce 
Williams and SOA Adoption For Dummies by Miko Matsumara, 
Bjoern Brauel, and Jignesh Shah. 


Icons Used in This Book 


To guide you through the book, we employ some icons. Here’s 
what they mean. 


Lots of pages in this book, and they’ve all got pertinent infor- 


mation. But if you’re in a hurry, at least be sure to pay atten- 
tion to these tidbits. 


We want to be helpful as you try to get your head around 
master data management, so here’s a constructive hint. 


Read this pointer to stay out of trouble. 
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Chapter 1 


Wrapping Your Head 
around MDM 





In This Chapter 


Defining master data and master data management (MDM) 
Understanding the business value of master data and MDM 


Understanding the basic architecture and functionality of MDM 


[: basic idea behind master data management, or MDM, 
is that your organization should have one version of the 
truth in its enterprise data. Who wouldn’t want one version of 
the truth, one standard set of records that any person or com- 
puter program can reference? That is, one definitive customer 
list, one completely accurate parts list, and so on. Yet, getting 
to that one version of the truth can be awfully challenging, 
even with the best of intentions. In this chapter, we define 
MDM in a way that will bring some order to the complexity of 
the subject and start you down the path to understanding the 
broader topic of process-driven MDM. 


What Is Master Data? 


Master data is information that is core to the running ofa 
business and typically refers to people, places, and things. 
Examples of master data include customer and product lists, 
part numbers, and addresses. 


These materials are the copyright of John Wiley & Sons, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


4 Process-Driven Master Data Management For Dummies 


To make this a little clearer, take a look at what is not consid- 
ered to be master data: 


M Transactional data relates to business transactions such 
as sales and purchases. In a sales transaction, the invoice 
number and total sale amount, in dollars, are examples 
of transactional data. Transactional data always refers 
to one or more types of master data. For example, an 
invoice is sent to a customer and lists the products 
purchased by the customer. 


Metadata is data about data. Metadata may describe a 
specific piece of data or a collection of data. Metadata 
facilitates the understanding, use, and management 
of data. For example, the metadata for a customer list 
would include information such as how long the cus- 
tomer name and address fields are and the type of the 
fields — such as if the fields are alphanumeric. 


™ Unstructured data is information that is typically found 
in user-generated documents. Word files, e-mail, spread- 
sheets, PDFs, and images are all examples of unstruc- 
tured data. 


Well, that sounds simple enough. What could be so hard 
about managing master data? Actually, there are a number 
of challenges to managing master data. Addressing those 
challenges is a theme we discuss throughout the book. 


What Is MDM and What 
Problems Does It Solve? 


The industry has developed a cool way to differentiate 
between master data and other data types. Think of master 
data as the “nouns” of business transactions. If a business 
transaction were a sentence, the verbs would be the buying or 
selling, and the nouns would be the buyer, his address, and so 
forth. For instance, take the following simple transaction: 


John Smith buys a red Cuisinart (SKU #A1223) and ships 
it to his home address. 


The master data “nouns” in this transaction sentence are 
“John Smith,” “Cuisinart,” “SKU #A1223,” and “Shipping 
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Address.” The “verbs” are “buys” and “ships.” The master 
data elements are people, places, and things; the transac- 
tional data elements describe what happens to those people, 
places, and things. The transaction record for the sale, shown 
in Table 1-1, might contain the following information. 


Table 1-1 Transaction Record for John Smith's 
Purchase of a Cuisinart 





Customer Dateof Product SKU# Shipping Amount 
name sale Sold Address 
John 3/1/11 Red A1223. 1 Oak Lane, $99.99 
Smith Cuisinart Chatham, MA 

02143 


The transaction record contains four master data elements: 
Customer, Product Sold, SKU #, and Shipping Address. This 
may not seem like a big deal. After all, don’t all transactions 
contain this type of information? Why all this fuss about 
calling the customer name a “master data element”? What’s 
different is that these master data elements appear over 
and over again in many different information systems in the 
corporation. The customer name in the transaction record 
should also be the customer name in the marketing depart- 
ment’s mailing list. If the customer name is different in each 
database, there can be errors, waste, and other business 
problems. MDM is about making sure that these master data 
elements are the same across all systems that need them. 
Businesses need to manage master data to keep it consistent 
and clean across multiple databases and systems. 


EMBER Not all people/place/thing data needs to be treated as master 


data. Industry practices suggest an approach to assess- 

ing whether data should be considered master data for the 
purpose of MDM. It’s a distinction worth making given the 
resources required to manage master data. Generally speak- 
ing, master data should meet the following requirements: 


A lot of data: If a company sells five products, the prod- 
uct list isn’t big enough to warrant MDM. Why would you 
need to? 


Volatile: Like infamous celebrities who change their 
shoes eight times a day, master data is volatile — although, 
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not as volatile as the transactional data that typically goes 
along with it. People move from place to place, get mar- 
ried and divorced, and so forth. If the company with five 
products never changes its product mix or descriptions, it 
doesn’t need a formal MDM effort to keep the data clean. 


M Value: There is no practical or cost effective way to 
perform MDM on all data in a corporation, so only high 
value data should be the focus of MDM. For example, the 
list of paying customers has value, so MDM is warranted 
to keep the list accurate and up to date. A list of poten- 
tial competitors also has value, but it may not be worth 
making it the object of MDM. 


™ Reuse: Master data tends to get reused across multiple 
business systems. For example, a customer’s shipping 
address will be used by a logistics system as well as the 
sales tax reporting software. If data isn’t being exten- 
sively reused, it is probably not worthy of being called 
master data. 


Causes of Master Data Problems 


If you haven’t been exposed to the underside of information 
systems much, the concept of data quality might seem a bit alien 
to you. How can data lack quality? Doesn’t data just exist or not 
exist? If it’s in the database, you have data, right? Not really. Just 
like any other business commodity, data varies greatly in qual- 
ity. However, unlike the chair with wobbly legs, which clearly 
lacks quality, low quality data can be a bit harder to spot. 


Data quality involves factors such as accuracy and complete- 
ness. For example, an address list full of misspellings and 
missing ZIP codes is of low quality. In the master data context, 
data quality extends the basic definition of data quality and 
adds the issue of data consistency across multiple systems. 
Thus, data quality issues with master data fall into the follow- 
ing major categories: 


Duplicate data: For example, two records for the same 
customer in the same system. Duplicates create the 
potential for conflicting data. 


/ Conflicting data: For example, a record for the same 
customer exists in two systems, but the addresses 
don’t match. 
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Incomplete data: Such as when a customer address is 
missing a ZIP code. 


Invalid data: Such as when a ZIP code in a customer 
address contains four digits instead of five. 


M Inaccurate data: For instance, when a customer owns 
three products, but the system says they only own two 
products. 


Drivers of Investment in MDM 


Master data management as a formal discipline has been 
around for over a decade. It is becoming increasingly critical 
as the business world — and its attendant information 
systems — grows more dynamic. Interest in MDM is being 
driven by many factors, including: 


Improving business processes: Operationally, businesses 
run on processes. Problems with master data lead to inef- 
ficient processes and subpar financial results. For exam- 
ple, mailing to duplicate addresses is a waste of money. 
Confusion about product SKUs and customer information 
can delay order fulfillment and result in higher error 
rates than expected — and cause customer dissatisfac- 
tion. Customer service quality inevitably suffers when 
good data about the customer and transactions isn’t 
readily available. Improving master data makes business 
processes run more smoothly and accurately. 


/ Improving decision making: Managers rely on opera- 
tional data when they make decisions that affect the 
business. For example, inaccurate sales forecasts (which 
can result from poor quality master data) can result in 
ill-advised decisions. 


Mergers and acquisitions (M&A): As any stressed out 
business operations and IT manager will tell you, com- 
panies tend to merge, divest, and acquire an awful lot 
these days. Although such activity might be great for 
shareholders, it can be a true pain for frontline business 
managers and database administrators. Merging multiple 
sets of master data (or keeping them separate) can be 
quite challenging. MDM helps keep it all straight, even if 
the work “just happens” after the fact. 
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M Compliance and liability: All businesses have to comply 
with government regulations, and some, such as financial 
services companies or publicly traded firms, must comply 
with a battery of overlapping rules and laws. In some 
cases, there can even be criminal liability for top execu- 
tives if compliance efforts aren’t sound. Data management 
is core to compliance, especially in situations that involve 
financial reporting. MDM can be essential in assuring that 
proper records are maintained for compliance purposes 
and in suitable condition to pass rigorous audit standards. 
MDM plays a similar role in helping mitigate the risk of 
civil legal liability. Issues such as warrantee notifications 
and product recalls, for example, all involve the use of 
master data. If, for example, a product recall notice was 
sent to the wrong address and a customer injured himself 
as a result of not being notified, this failure to notify cus- 
tomers could result in legal liability for the business. 


The blurring perimeter: In the good old days, when 
computers sat in large glass rooms and men with crew 
cuts managed every inbound and outbound byte on 
punch cards, MDM was less of an issue than it is today. 
Yet, even then, similar challenges arose. Today, recent 
advances in corporate computing have thrust MDM to 
the forefront. Data can reside anywhere, making MDM 
necessary to keep master data clean and consistent: 


e Distributed computing: This is not exactly big 
news, but for MDM purposes, bear in mind that 
computer systems today are broadly distributed. 
Software programs run anywhere, accessing data or 
updating and deleting records across any number 
of integrated systems. 


Service-Oriented Architecture (SOA) and Business 
Process Modeling (BPM): Although integration 
between multiple software programs has long been 
possible, the rise of SOA, which exposes applica- 
tions and data sources as universally accessible 
services over the network, amplifies potential chal- 
lenges in managing master data. Combined with 
BPM, which enables application developers to 
assemble new applications rapidly using business 
process workflows that are connected to underly- 
ing software elements, SOA creates an environment 
where use of and modifications to master data can 
be impossible to track without effective MDM tools. 
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The Business Value of 
an MDM Solution 


MDM solutions can have significant business value if they’re 
executed properly. Master data can have an impact on the 
bottom line. Master data is the critical connector between 

the enterprise systems that underlie most business opera- 
tions. And, master data provides the essential link between 
operational systems and the business intelligence solutions 
that support management’s decision making. The quality of an 
organization’s master data, therefore, can affect the quality of 
its operations and strategic decision making. 


MDM in operations 


Operationally, good master data management facilitates effi- 
ciency. At many large enterprises, transactions are processed 
by more than one connected system. MDM makes it possible 
for this cross-system operation to occur without requiring too 
many manual inputs to correct discrepancies between master 
data elements. For example, if a billing system and general 
ledger system refer to different customer name records, that 
discrepancy might necessitate a manual correction. A simple 
consumer product, such as a bottle of soda, may be repre- 
sented in a dozen different ways in a dozen back-end systems 
at the bottler. The billing software might refer to the bottle as 
item #123, while the ERP system might know it as SKU #123A. 
This is a breakdown in MDM, and it can cause mistakes, such 
as overbuying of supplies or errors in billing. Other examples 
of business problems that can arise with poor MDM include: 


M A mortgage lender that repeatedly sends solicitations to 
an existing loan customer, causing confusion, potential 
customer service support issues, and a waste of market- 
ing dollars. 


M Acredit card company that sends bills to an out-of-date 
address and eventually puts the account into collection, 
even though the customer is unaware of what is going 
on. The company loses an otherwise good customer and 
creates ill will, and perhaps even legal liability. 
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M A publicly traded company violates the Sarbanes-Oxley 
Act by maintaining deficient financial controls — for 
example, misstating its expenses in an accounting period 
due to inconsistent master data about vendors in its 
general ledger and ERP systems. 


MDM in business analytics 


Business data is a constant factor in management decision 
making, often relying on reporting (business intelligence, or 
BI) solutions to parse and interpret operational data. Master 
data is one of the essential elements of BI. The better master 
data is managed, the more accurate and effective the BI will 
be. To illustrate this idea, consider how master data factors 
into hierarchies between sets of data. In the soft drink exam- 
ple, the bottler needs accurate information about how many 
units of each SKU are sold in each territory. The hierarchy 
of data in this situation would include relationships such as 
SKU/Territory and Territory/Sales Manager. 


The BI solution must be able to present an accurate report 
about which Sales Manager sold the most SKUs. Master data 
management is responsible for assuring that the relationships 
between data sets accurately reflect the operational reality. If 
it doesn’t, senior executives might make decisions based on 
erroneous data. 


Basic Approach and Architecture 
behind MDM 


Now that you have a grasp of what MDM is, you’re probably 
wondering how it actually works. The second half of this book 
gets into great detail on this topic, but we want to introduce 

a few key concepts at this point. MDM is all about unifying 
master data and enabling operational and analytical systems 
to access and use it easily. An MDM solution has to be able to 
identify conflicting instances of master data, correct the con- 
flict, and create a single standard record or golden record for 
subsequent use. All in all, system integration is a requirement 
for MDM to work. 
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There are several distinct techniques to achieving this result, 
and they all involve a set of core processes. 


Data harmonization and cleansing: Master data is con- 
solidated (pulled together from several sources in one 
database). Dependent on sorting criteria and predefined 
rules, duplicates are identified and eliminated. Finally, 
the remaining master data records are cleaned up and/ 
or enriched before they can be used. This technique is a 
prerequisite for successful one-time master data migra- 
tions but also for master data governance ensuring ongo- 
ing master data quality assurance. 


Data migration: Master data needs to be in one acces- 
sible place, so when formerly separate databases are 
brought together, it’s necessary to migrate the data into 
the database that holds the master data. This sounds 
simple but it isn’t. 


System integration: In order for systems to access 
master data, they need to be connected to the sources of 
master data and the solutions that assure that the master 
data has the required integrity for use. System integra- 
tion is a prerequisite for data migration as well as for 
permanent interfaces. Typical scenarios include: 


e Distribution of customer master data from CRM to 
an ERP system where it is enriched for order fulfill- 
ment purposes (billing, shipment, and so on) 


e Request tool for providing master data automati- 
cally to an ERP system after approval of the form 
via status change trigger 


e Upload of basic product data after design release 
from PDM (product data management) tools and/ 
or parametric CAD applications to ERP where these 
product data are enriched with additional informa- 
tion for logistic and production processes 


All in all, system integration is a requirement for MDM 
to work. 


These techniques play a substantial role in architectural 
decisions for technical MDM implementation. They also need 
to be applied in a structured way. Therefore process scenarios 
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for preparation and provisioning of master data can be defined. 
MDM scenarios for provision and governance of master data 
are important support processes ensuring timely provision 

of high-quality master data to value generating business pro- 
cesses. These process scenarios are visualized in Figure 1-1. 


Operative Master Data Provisioning and Maintenance (Master Data Life Cycle) 


Request new Check and Maintain global Maintain local Execute MD Archive MD 
MD/ MD change approve request / [f MD (centrally) MD(e.g. by plant) discontinuation 

Provide MD from Check and 

external systems approve MD 


Migratory Master Data Provisioning 
i Extract MD Consolidate ; Cleanse and F 
H i from legacy and standardize Sune 0 enrich MD BeclhilD 
legacy systems systems MD (migratory) (migratory) target system 
Master Data Governance/Ongoing Master Data Quality Assurance 


Monitor MD Harmonize MD Cleanse and 
quality enrich MD 


Figure 1-1: MDM scenarios for provision and governance of master data. 





The mechanics of MDM aren’t simple, but they’re fairly 
straightforward. The difference between success and failure 
with MDM, however, depends on how well you understand 
the all-important people and processes involved. If the “what” 
of MDM is the data itself, the “who” and “how” are absolutely 
critical to making the MDM effort a business success. 
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Chapter 2 


Thinking about MDM from 
a Process Perspective 


In This Chapter 


Understanding the limitations of a data-focused approach to MDM 
Getting an overview of process-driven MDM 


Starting to think about MDM from a business perspective 


[°: chapter helps you take the next step to seeing MDM 
as part of a bigger business operations picture. It’s this 
bigger picture that will be a constant backdrop to the discus- 
sions of MDM in this chapter and throughout the rest of the 
book. Business and data are never far from one another. Given 
the critical role of data in business processes, the relationship 
between businesses and their data is the essence of process- 
driven MDM. 


MDM Is about Data, but 
Not Only about Data 


As its name implies, master data management concerns data. 
Yet, it is about far more than just bits and bytes. MDM has 
much more to do with running your business better. Why is 
this the case? The reason that MDM is about business, not 
just data, is that data is at the very heart of all businesses. 
Businesses run on data. What company can operate efficiently 
if it doesn’t have an error-free list of its customers and prod- 
uct information, for example, or if some departments have 
outdated product information? 
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The scenario shown in Figure 2-1 illustrates how successful 
(or unsuccessful) business activity truly revolves around 
effective creation and management of master data. In today’s 
business environment, rapid growth, organizational change, 
and mergers and acquisitions (M&A) can mesh poorly with 
fragmented IT systems, siloed databases, and deficient master 
data. The result is business processes that are inefficient and 
that lead to less-than-optimal decision making. This problem 
is then compounded by poor regulatory compliance. 
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Figure 2-1: Mergers and acquisitions, combined with fast growth and 
fragmented IT systems and poor MDM, contribute to negative operational 
and compliance results. 


But when MDM is done right, the pace of business change 
can run at maximum speed. Supporting IT systems can be 
heterogeneous, and even tend toward siloes, as long as the 
crucial master data has the quality to keep the processes well 
aligned. 


We use the example of a tire manufacturing company as a 
case study in the relationship between data and business 
operations. Figure 2-2 shows the relationships between the 
manufacturer and its dealers. There are two channels of infor- 
mation between the manufacturer and its retailers: the mar- 
keting system/database and the inventory/ordering system/ 
database. Lacking coherent MDM, the manufacturer routinely 
sends conflicting information about tires (the tires represent 
the master data object causing the inefficiencies in this case 
study) that are available for sale. A tire that has been discon- 
tinued is accidentally offered as a promotion. Dealers order it 
in large quantity, only to be told that it is no longer available. 
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Such incorrect orders can’t be fulfilled. This results in a 
confusing cycle of reorders, low dealer inventory levels, and 
dealer frustration. Customer service representatives at the 
manufacturer are also frustrated, which affects workplace 
morale and customer satisfaction. 
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Figure 2-2: Master data and resulting operational problems ata tire 
manufacturer. 


The problems faced by the tire manufacturer may seem like 
routine business aggravations and not all that costly for the 
operation. That view is both true and deeply false at the same 
time. Okay, you think, an incorrect purchase order isn’t going 
to kill anyone. One or two phone calls and it’s fixed (though 
even that is more costly than you might believe). Also think 
about it like this: What is the cost of having your business 
look as if it doesn’t know what it’s talking about, the left hand 
never sure what the right hand is doing? “Hello, want to buy 
some tires that | am not sure exist any more? How many 
would you like?” What does that do for your image? Can you 
imagine how your product quality will be perceived when 
every third PO needs a phone call to clarify and reorder? Your 
competitors will be licking their chops to go after you. 


What's Wrong with the Data- 
Focused Approach to MDM 


If you were a database administrator at the tire manufacturer 
depicted in Figure 2-2, you would likely want to see changes 
in the way master data was handled in the company. You’re 
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probably getting heat for the problem anyway, with constant 
crisis calls from upstairs to clear up discrepancies between 
product names and numbers that are causing trouble in the 
ordering process. You might initiate some kind of project to 
clean up the master data mess. This will be a well-intentioned 
but ultimately highly problematic approach to getting MDM 
right. 


In our experience, MDM initiatives that are planned and 
executed by the IT group without close involvement by the 
business are destined for serious challenges or even failure. 
They’re sort of like eating soup with a fork: lots of action, not 
a lot of results or satisfaction. A number of causes contribute 
to this situation. Prominent issues emerge on the following 
fronts: 


 IT-initiated and IT-driven MDM with limited business 
involvement. It makes perfect sense for an MDM project 
to be initiated and managed through IT. However, it’s 
not ideal, because business stakeholders may be left out 
of the picture or led to believe that MDM is purely an IT 
issue. That is a mistake. Without business people, IT will 
struggle to scope the MDM program, define data quality 
rules, and implement policies and procedures to keep 
data clean and consistent on an ongoing basis. 


M Periodic attempts to clean up a data mess. Data quality 
tends to go down over time. Many companies periodi- 
cally reactivate master data cleansing projects without 
investigation of the root cause. This approach becomes 
akin to shooting at a moving target. The problem is never 
truly solved and will continue to resurface. 


Y The (half right) objective of addressing only data man- 
agement and quality challenges. If delivering clean, 
consistent master data is the only stated goal of an 
MDM project, that project is going to suffer. Business 
stakeholders don’t care (or don’t understand) what is so 
important about MDM. IT may end up focusing on lower 
priority problems or creating half-baked solutions that 
don’t generate enough value for the business. And, even 
IT stakeholders might not take the whole thing very seri- 
ously. To be fair, IT people are under enough pressure 
with their own responsibilities that they need a reason 
to be interested in what might seem like an esoteric data- 
base management issue. 
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Y The (admirable but misguided) focus on disjointed data 
and data definition in system silos. A lot of MDM proj- 
ects amount to a relatively small team attempting to boil 
the ocean by improving MDM across multiple systems 
and departments. Boiling the ocean is one of those great 
IT metaphors, kind of like eating an elephant, herding 
cats, or riding goats in a rodeo. Say what you want about 
us boring IT folks, but we have a lot of really good meta- 
phors. This approach, which is admirable, is virtually 
guaranteed to fail, at least in terms of delivering business 
results soon enough to retain management support and 
funding for the project. 


M Aiming at but missing real ROI through data manage- 
ment and quality metrics. An inherent flaw in many 
data-focused approaches to MDM is the use of IT-based 
metrics to define success. There is nothing wrong with 
setting an objective such as reducing duplicate master 
data or addressing errors in an MDM project. However, 
these types of measures are neither meaningful to busi- 
ness stakeholders nor even other IT groups. The MDM 
project that attains some stated target of duplicate 
reduction usually doesn’t hit the “big whoop” factor. The 
CIO might react to the project by saying, “Good for you, 
guys. Now, go do something that will help the business.” 


/ Undervaluing organizational realities. An MDM program 
will often require changes in how business creates and 
consumes data. For example, if customer data exists 
in two departmental systems, you may have to picka 
winner and convince the other department to comply 
with the master data. IT managers alone usually can’t 
create the case for such decisions and changes. To 
borrow a sports simile, IT is to the business what the 
physical trainer is to the football star. They’re the very 
important behind-the-scenes enabler of success, not the 
main attraction. For this reason, an MDM project that is 
driven by IT and focused on IT-based goals will typically 
have a hard time proving itself worthy of attention and 
investment. A lone IT manager is going to have a heck 
of a time persuading system owners and business stake- 
holders to change the way they do things. 


a? In order for MDM to work, it must be an effort that brings 
business and IT together in equal measure. What’s needed is 
some kind of special “glue” to get these two separate groups 
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to come together and stay focused on MDM as an issue that 
must be resolved to benefit the business overall. The good 
news is that the glue already exists, though not everyone 
involved in MDM is aware of its potential to invigorate MDM 
projects. It’s called process. 


Process-Data Connection 


The word process is a much used and abused term in the 
business world. It has many different meanings in different 
contexts. Even among people with similar training and objec- 
tives, the word can be simultaneously misunderstood. For our 
purposes, however, a process is going to be defined as a set of 
steps required to perform some kind of operational function in 

a business. A process also encompasses triggering events and 
input information required to perform each single process 
step. Completion of a process step leads to output informa- 
tion and a resulting event representing the triggering event for 
the next process step and so on. Additionally, each process 
step should have at least one role (with assigned people) that 
is responsible for execution of the process step. For example, 
the process required for accepting an incoming order for tires 


might look like Figure 2-3. 
Enter order Fulfill order 
into inventory/ 
order system 





Receive 


Purchase 
Order 







Check 
if tire is 
in stock 


Contact 
customer and 
modify order 


Figure 2-3: Simplified order process for the tire manufacturer, showing 
how the incoming order needs to be checked against inventory before 
fulfillment. 


Figure 2-3 shows a simplified business process flow for an 
incoming order at the tire manufacturer. The order comes in. 
A customer service representative checks to see whether the 
tires are in stock. If they are in stock, the order is processed. 
If they are no?, the rep calls the customer and sees if it is pos- 
sible to modify the order. 
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What does process have to do with data? A lot, it turns out. 


19 


Each step of the process involves a person interacting with an 


information system and related database. If inbound orders 
are in electronic form, then every step involves IT. The cus- 
tomer service representative queries the inventory/order- 
ing system to check if the tire is in stock. He or she enters 
the order into that system if the tire is in stock. Thus, even 
though the process is a business matter, it’s really about flow 
of data. Does the inventory database say “Yes” or “No” to the 
question of whether the tire is in stock? 


The master data problem arising at the tire manufacturer can 
be seen right in the middle of this process. In the absence of 
an effective MDM solution, potential master data problems 
abound. For instance, the inbound P.O. could specify a tire 
that is no longer manufactured or list the wrong product 
code. The wrong price could be applied to the invoice, and 

it could be shipped to the wrong address or to a different 
dealer altogether. 


Why is it helpful to discuss MDM in the context of process? 
The reason is that process flows are the way that business 
people typically see their world. Business processes are 
where data comes alive. Whether or not they use flowcharts, 
business managers understand steps in a process far better 
than they understand data or esoteric IT issues. When an IT 
person and a business stakeholder plan an MDM project, a 
discussion of the interaction between process and data will 
make the whole topic a lot more practical and real than a 
purely data-focused approach. 


Hello! Introducing 
Process-Driven MDM 


Now that you get how data, software, and business processes 
are essentially connected, it’s time to introduce process- 
driven MDM (PDMDM). PDMDM turns master data improve- 
ments into business advantage by focusing on high impact 
process improvements. For example, in the case of the tire 
manufacturer, PDMDM would look at ways to improve the 
order-taking process through MDM. Instead of focusing on a 
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data metric, such as the number of incorrect tire SKUs in 
the inventory database, PDMDM would approach the order 
process by seeing how MDM could reduce the number of 
incorrect orders. In this way, PDMDM creates tangible ways 
to measure MDM ROI and guide MDM investment. 


The objective of PDMDM is to improve business processes by 
improving the quality of data they use. In the tire manufactur- 
ing example, they can reduce errors in the order process by 
improving master data quality with a good MDM solution. The 
focus is on data needed by business processes, not data for 
its own sake. Business stakeholders gain a much more clear 
and relevant reason to be involved in MDM. 


Looking at how PDMDM works 


We want you to have a high-level sense of how PDMDM works 
before we get deeper into the subject. Unlike a data-focused 
MDM project, which begins and ends with the database, a 
PDMDM initiative starts with process analysis. The four main 
steps of a PDMDM project flow along the following lines: 


1. Process Analysis 


e Identify processes impacted by poor master data 
(for instance, the tire ordering process). 


e Describe data quality (DQ) issues impacting pro- 
cess performance (for example, how inconsisten- 
cies between the inventory and manufacturing 
systems create repeated correction loops in the 
ordering process). 


Quantify key performance indicators (KPIs) that 
show the effect of poor master data on process 
performance (for example, time to complete 
order transaction, delay in order delivery, 
errors, and so forth). 


Identify which master and reference data is used 
by processes (for example, tire SKU#). 


Describe how data is used by processes: created, 
enhanced, modified, deleted, and so on. 
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e Describe data elements needed by process steps. 
e Identify stakeholders/users of data. 


e Identify current ownership and governance prac- 
tices (or lack thereof). 


2. Data and IT Architecture Analysis 


e Identify source/target systems where process 
master data resides (for example, tire product 
DB, inventory/ordering system, marketing 
sales DB). 


e Analyze data models in systems at the attribute 
and relational level. 


e Define mappings back to source/target systems. 


3. MDM Blueprint and Design 


e Define the physical data model, solution archi- 
tecture, and data quality rules. 


e Setup a Governance Board and processes. 
e Define needed process changes. 


e Define success/return on investment (ROI) moni- 
toring KPIs (based on process KPIs from process 
analysis phase). 

4. Implementation and Rollout 


e Implement MDM solution, data cleansing, and 
data migration. 


e Implement organization and process changes. 


e Regular reviews and optimization of MDM tech- 
nology and processes. 


Understanding why 
PDMDM is better 


So who should actually own an MDM initiative? Although IT is 
typically the owner of an MDM project, this isn’t always ideal. 
Truly, MDM should be business-owned. When the business 

understands the value of MDM in business terms, as they will 
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when the results are evident in process improvements, they 
will have an interest in investing in MDM and a real stake in 
its success. 


With business stakeholders in the driver’s seat of PDMDM, it 
becomes more realistic to create tangible ways to measure 
MDM ROI and guide MDM investment. To a business owner, 

a tangible measure of ROI is typically one that involves finan- 
cial results. For example, as Table 2-1 shows, the tire manu- 
facturer can project two potential areas of savings from the 
implementation of PDMDM in the tire order process. The man- 
ufacturer can reduce the percentage of orders with errors, 
but also cut the time required to fix the errors. One problem 
that has been plaguing the manufacturer is the fact that the 
customer service representative has to contend with conflict- 
ing inventory data when solving an erroneous order. PODMDM 
takes care of both problems. 


Table 2-1 Savings/ROI Tire Manufacturer Example 
Status Quo After 


PDMDM 
Number of orders per year 100,000 100,000 
Percent of orders with errors 5% 1% 
Number of errors per year 5,000 1,000 
Time required to correct error (hours) 0.25 0.1 
Total time spent on errors 1,250 100 
Labor cost, fully-allocated (per hour) $75 $75 
Cost of errors in order process $93,750 $7,500 


Savings $86,250 


It may not be possible for the manufacturer to forecast 
precisely how well PDMDM will do in generating savings. 
However, PDMDM enables business stakeholders to develop a 
real, financially meaningful measurement of how PDMDM can 
benefit the business. They can set targets and track results 
from there. PDMDM puts business into the driver’s seat and 
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takes IT out of the hot seat. (Who wants to be in the hot seat, 
anyway?) It’s a win-win for both sets of stakeholders. 


The PDMDM approach lets business owners focus on pro- 
cesses by way of data. Master data needed in business pro- 
cesses gets quality improvement. This is an advantage over 


having a data-focused approach that spins cycles improving 
data no one cares about. 


In general, we summarize the value of PDMDM in three main 
points: 


™ Invest in improving processes that really matter and 
avoid wasting money on low value results. 


M™ Ensure that the MDM investment will create business 


value at the end of the day, giving the business a reason 
to get involved. 


M Enable measurable and faster ROI. 
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Chapter 3 


The Three Pillars of 
Process-Driven MDM 


In This Chapter 


Furthering the discussion of MDM as a business issue 





Connecting MDM with the drivers of business value 


Expanding the connections between process and MDM 


Ss: many topics in IT can sound vague at times. The high 
level concept sounds great, but the details can be elusive. 
How many times have you heard an IT person say something 
like, “This is enterprise-ready technology,” and you thought 
“Huh?” This chapter is about going a level or two deeper and 
developing a true sense of how PDMDM can benefit a busi- 
ness. To make sense of it, we organize the business aspects of 
PDMDM around three pillars: 


MDM is a business-driven discipline supporting process 
optimization or transformation. 


MDM program scope is directly driven by process opti- 
mization needs, and MDM investments are tied to and 
measured by process improvement ROI. 


MDM should follow a cross-disciplinary approach involv- 
ing people from different functions or business areas 
impacted by the processes being optimized. 


We discuss these three pillars in this chapter. 
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Pillar #1: MDM Is a Business- 
Driven Discipline 


If you think about it, the real owners of master data in an organi- 
zation are on the business side of the house, along with business 
support functions such as finance. They’re the ones who have 
the knowledge to determine whether there are any errors in 
master data, and they’re the stakeholders whose lives are made 
easier (or tougher) by well-maintained (or poorly maintained) 
master data. That means that master data information has a key 
impact on value-generating business processes. A good first step 
in thinking about MDM, therefore, is knowing that business users 
have to get involved with any MDM initiative. 


However, just being “involved” isn’t good enough! In order to 
ensure that the MDM effort successfully navigates the slings 
and arrows of outrageous corporate politics, it has to be spon- 
sored by an influential business leader and owned by a key 
business user. Thus, even though MDM may be IT-initiated, 

it should be business-owned and business-driven. So, with 
your business owners lined up and ready to go, do you know 
exactly what it is that they want to accomplish? Business, 
right? But what does that mean in practical terms? 


Taking care of business 


Calvin Coolidge, the early 20th century U.S. President, is 
famous for saying, “The business of America is business.” 

And the business of a business is business. That may sound 
obvious but so much of the time it’s easy to forget this simple 
truth. Business can seem to be about so many other things — 
people, technology, egos and personalities, fads and trends — 
that you can take your eye off the ball. The goal of business 

is to generate strong, growing returns for shareholders. In 
theory, every action you take in a business should push 
toward the achievement of that goal. By extension, you should 
prioritize your MDM efforts on master data that is key to 
business stakeholders. 


Though there are many ways for a business to increase its 
value to shareholders, most methods involve improving 
operational cash flow without a commensurate increase in 
investment. In other words, businesses become more valuable 
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when they increase their return on assets (ROA). So if it costs 
$1 million to open a store, and the store generates $100,000 
of income, that’s a 10 percent return on the asset created by 
shareholder investment. If some number of operational and 
strategic changes can be wrought to grow that cash income 
to $150,000 a year, the return on the $1 million store asset 
has increased to 15 percent. 


In most cases, the higher the return on assets is, the more 
valuable the investment will be. A good executive will always 
see a direct connection between strategic and operational 
decisions, return on assets, and share price. 


Data is integral to business value 


Data is integral to many standard methods of building share- 
holder value. As a result, MDM can and should be a key ingre- 
dient in business activities that increase return on assets 
either directly or indirectly. The following sections discuss 
this in more detail. 


Value chain improvements that increase return on assets 


Every business has a value chain, the sequence of activi- 

ties that take raw inputs, including material and labor, and 
transform them into something of higher value. For example, 
think of a tire manufacturer, which can take a set amount of 
rubber and produce either a cheap, generic tire or a unique, 
high-priced tire for a specialized vehicle. Though the costs of 
the inputs may be identical, the latter tire has a much greater 
value than the former. The difference between the two prod- 
ucts is the value chain, which in this case includes activities 
such as research, engineering, and manufacturing processes. 
Data flows throughout each of these processes. Master data 
issues will likely surface in the manufacturing process, where 
MDM can help make the difference between moderate and 
outstanding success in value chain enhancement. 


Operational process improvements that 
increase return on working capital 


All businesses face pressure to manage working capital. The 
more efficient the working cash cycle, the higher the return 
will be on the working capital investment. To understand how 
this works, think about a tire manufacturer’s expenditure and 
receipt of cash for its products. 
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A certain amount of time elapses between the moment when 
the tire company buys the raw materials and pays its oper- 
ating expenses and salaries to produce a tire and the day 
when a customer sends in a check to pay for that tire. The 
longer that elapsed amount of time, the more working capital 
the tire company will need to operate. (fo remember how 
this works, one of the authors thinks of his grandmother, a 
medical secretary, who referred to all fast-paying patients 

as “such lovely, fine people,” and the slow payers as “those 
troublemakers.”) 


In the meantime, during that agonizing middle period after 
the money has been spent to produce the tires and before 
the happy instant the customer’s check clears, the company 
will have to come up with some cash (working capital) to 
tide it over. That money can either be borrowed or paid in 

as investor equity. In any event, the more rapid the cycle of 
converting orders to cash, the less working capital required 
and the stronger the returns will be to shareholders. MDM is 
at the heart of this working capital cycle. For example, reduc- 
ing order processing errors with high quality master data can 
reduce delays in getting paid and speed up the cash collection 
process. Or, understanding which customers are truly the 
best (fast payers with few returns) and rewarding those 
customers will push up returns on working capital. 


Agile transformation of business processes 
to align with changing strategies 


Business conditions are constantly changing. Companies that 
can shift their processes to adapt to new strategies have a 
better chance of benefiting from market trends than slower, 
more rigid competitors. 


IT and master data are key ingredients in an agile trans- 
formation of processes because they’re often the central 
mechanism of operational change. For example, if the tire 
manufacturer decided it wanted to expand its reach to smaller 
distributors by allowing customers to pay with a credit card, 
that decision would effect a change in the order payment 
process. For an organization with good MDM, making a move 
to accept credit cards will be easier because reliable product 
data needed to market and sell goods via this new channel is 
readily available. Without MDM, the credit card option will 
inevitably take longer and cost more to implement, and it 
will likely yield more problems as it is implemented. 
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Process improvements that build customer retention 


Customer retention is a multifaceted activity, but process 
improvements and data management are at the heart of it. 
The better you can service your customer, the more likely he 
or she will remain loyal. Good service involves understanding 
your customer, knowing what he or she wants, and anticipat- 
ing needs. It means solving problems easily and developing 
trust and confidence. All of this revolves around solid IT 
support for business processes and good PDMDM. 


Tt all depends on your perspective 


Thinking about PDMDM as a business-driven discipline 
requires a stretch for both the IT and business sides of the 
PDMDM conversation. (We’re assuming there’s a conversa- 
tion going on about MDM, because if there isn’t, that’s your 
first problem.) At the risk of being simplistic, we think it’s 

fair to say that IT people and business people tend to have 
somewhat different perspectives and perceptions on and of 
processes, systems, data, users, and customers. As Figure 3-1 
illustrates, IT systems and databases usually loom large when 
IT people think about the connections between business and 
IT. Conversely, business people, especially senior managers 
who usually write the checks for IT investments, often see the 
customer (and the customer’s wallet) in the sharpest focus, 
while the IT systems that make the whole process work are 
simply the means to an end. Process-driven MDM brings both 
sides closer to each other; it’s a business driven discipline that 
balances business and IT perspectives, agendas, and needs. 


We always like to say that in PDMDM you should treat data as 
if it were an asset of the business. Two questions arise imme- 
diately from this idea. For one thing, why? And, is data really 
an asset? 


Why should data be viewed as an asset in PODMDM? The 
reason is that data needs to be treated as a valuable part of 
the business, a costly asset that can be harnessed to create 
shareholder value. There is a temptation for business man- 
agers to look at data as a necessary but essentially invisible 
and worthless component of transacting business. IT people, 
in turn, can make the same mistake, seeing data as bits and 
bytes that flow through systems, but not as a business asset. 
Both views are flawed. 
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Figure 3-1: How IT and business see customers. 


When you see data as a business asset, it should be clear that 
return on data assets (ROA) needs to be a constant objective 
of corporate IT. Process-driven MDM is a major lever of ROA 
for the data asset. 


Pillar #2: Process Optimization 


MDM program scope is directly driven by process optimiza- 
tion needs, and MDM investments are tied to and measured 
by process improvement ROI. 


Figure 3-2 shows how process improvements lead to growth 

in operational income, which contributes to growing returns 

to shareholders. Increasing the income from existing business 
assets is always good for the bottom line and shareholders. 
MDM can be an important part of improving the processes that 
drive these much-desired gains in business value. PDMDM is 
about locating MDM squarely in the process improvement arena. 


areas Improved Improved Improved 
improvement operational return on return to 
income business assets SJ arelachalellelsvas 





Figure 3-2: The transition from process improvements to returns to 
shareholders. 
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When defining the scope of an MDM initiative, therefore, it is 
essential to frame the goals and requirements of the project 
in process terms. If you’re an IT person dealing with busi- 
ness managers, you will get far more buy-in and investment 
for MDM if you can frame the project in terms of increasing 
return on assets through process improvement than you will 
if you state your goals in an IT or data-centric way. 


IT people, keep this in mind: Whether you actually hear it or 
not, you're always being asked the same question by busi- 
ness stakeholders: “How can you help me make more money/ 
increase return on assets/build shareholder value?” You can 
answer this question without waiting to be asked by framing 
MDM in terms of process improvements that create better 
business results. 


For instance, imagine that you’re an IT person at a tire manu- 
facturer presented with the following problem: Customer 
service representatives (CSRs) report that they’re frequently 
being troubled by duplicate accounts in the inventory/ 

order management system. Many times, the customer gets 
two statements for two different amounts of money because 
the CSRs don’t see that there are two separate listings for 
the same customer. In addition, phone inquiries take longer 
to handle because CSRs have to look at multiple customer 
records to find transactions. 


What the company needs, you reason, is a good MDM pro- 
gram, with the goal of reducing duplicate account data by 80 
percent. Your approach is totally accurate but entirely inef- 
fectual when it comes to getting support (and budget) from 
business stakeholders. They’re simply not going to get all that 
excited about an 80 percent decrease in duplicate account 
data, even if they understand the connection between dupli- 
cate data and customer support problems. And, be honest. 
You're probably not that excited about it, either. 


If you define the scope of the MDM project in process terms, 
you will be able to get to an ROA estimate such as the one 
shown in Table 3-1, which states its impact in terms of 
improvements in orders processed per year by the same 
group of customer service representatives. This approach 
looks at the MDM elements of the process that affect how 
many transactions the CSRs can fulfill in a year. If the MDM 
project can result in process improvements that enable the 
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CSR facility to complete more transactions per year, then the 
ROA for the CSR facility itself will grow. That is, for the $10 
million that the company invested to build, equip, and staff the 
CSR facility, they will now enjoy $2.6 million in profit — without 
increasing staffing — versus the current $2 million they cur- 
rently earn. Similarly, the $1 million in CSR salaries (working 
capital) that the company expends for customer service will 
now yield a higher return. This metric is reflected through the 
cost per transaction, which shrinks from $10 to $7.69. 


Table 3-1 Return on Assets (ROA) 
fora PDMDM Project 
As Is After PDPMDM 

CSR overhead $1,000,000 $1,000,000 
Transactions processed/year 100,000 130,000 

Profit per transaction $20 $20 
Cost per transaction $10.00 $7.69 
Profit per year $2,000,000 $2,600,000 
CapX for CSR facility $10,000,000 $10,000,000 
ROA for CSR facility 20 percent 26 percent 


Where is the duplicate data reduction metric in this table? Of 
course, it’s not visible, but it’s there. The MDM improvement 
is what drives the process gains, resulting in a 30 percent 
jump in order processing capacity from the same number of 
CSRs. This is the kind of performance data that a business 
stakeholder will understand and underwrite. 


Pillar #3: Cross-Disciplinary 
Approach 


MDM should follow a cross-disciplinary approach involving 
people from different functions or business areas impacted by 
the processes being optimized. 
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Are you ready for a serious revelation about IT? Okay, here 
goes: IT isn’t about technology, nor information; IT is about 
people. Yes, computers are involved, of course. (it is IT, after 
all.) But, where it really matters, IT is just about 100 percent 
a human-oriented business. IT people are people (gotta point 
that out, for some of you out there). Business stakeholders 
are people. Customers are people. IT vendors and consultants 
are people. People write software and design systems for 

use by other people, or for machines that ultimately service 
human beings. Solving IT problems is almost always about 
solving people problems and cooling down disagreements and 
negotiating compromises. As a result of this ground-breaking 
insight, we encourage you to think about MDM in human 
terms, with a cross-disciplinary approach where people 

and technology work together for process improvement. 


The increasing workload employees take on today results in 
compartmentalized job functions. Although this is necessary 
to run a business, it can make MDM fairly challenging. Each 
business process in an organization will typically impact mul- 
tiple business areas, functions, or departments. In order for 
an MDM program to be successful in the long run, representa- 
tives from each of those areas should be included and con- 
tributing to the program. 


Each person has a different outlook on business as well as dif- 
ferent incentives and agenda. Each one has unique skills and 
insights, though no individual has all the knowledge and skills 
to make MDM a success. 


There is no one right way to get multiple disciplines to work 
together for MDM, as each organization and group has its own 
unique culture. We have some recommendations, however, 
based on many years of doing this kind of thing: 


Mw Every MDM initiative must have senior executive spon- 
sorship from the business side, matched with executive 
buy-in from senior IT managers. 


M You absolutely must have a central steering group (or 
committee, or virtual team, or whatever you want to call 
it) that comes together regularly to form a plan, agree on 
goals, and track performance. 
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M Each specialty represented in the group must be given 
the opportunity to weigh in on the goals of the MDM proj- 
ect. This assumes, though, that everyone is familiar with 
what MDM is all about, which brings us to the next point. 


The group needs to have some education in MDM. This 
education doesn’t need to be anything elaborate or time- 
consuming. But, the business and IT people involved in 
MDM must have a good grasp of what MDM is all about. 
In fact, they should all read this book. (Phew! Found an 
audience, hurray!) 


M Thus formed and newly aware of MDM, the group has to 
focus on the business-facing approach to MDM that we 
have outlined in this chapter. 


Ultimately, you will have to find your group’s correct path to 
MDM success. If you stick to these three pillars and focus on 
process improvements, ROI on process, and ROA for the 
business, you will be on track to realizing the business 
potential of Process-Driven MDM. 
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Chapter 4 


Like Goldilocks: Finding the 
“Just Right” MDM Projects 


In This Chapter 
Understanding how to find the most promising MDM projects 


Factoring common MDM problems and business pain points into an 
organized MDM assessment process 


Planning for both PDMDM projects and an overall PDMDM initiative 
Getting a deeper understanding of the MDM project process 





GF: went looking for a chair to sit in. One was too 
big, another was too small. Finally, she found one that 
was “just right.” So it goes with PDMDM. Although it’s not 
difficult to find numerous business processes that could ben- 
efit from MDM, some are better candidates for PDMDM than 
others. It’s wise to pick your first project carefully. 


Where to Start? 


If you’re going to start looking for the right MDM project, 

it makes sense to define what that project might look like 
before you get too far into your search. Otherwise you might, 
to paraphrase the great Steven Wright, walk halfway across 
Texas looking for your dog, only to discover that he was right 
behind you the whole time. 


An MDM project is a discrete, time-limited piece of work 
intended to improve the management of a selected set of 
master data in a specific business process. For example, 
you might decide you want to improve the accuracy of your 
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orders and reduce order processing costs. To accomplish this 
goal, you undertake an MDM project related to the data con- 
nected with the order process. 


This order process MDM project will hopefully be just one 

of many that you conduct over the long term. It should be 
part of an overall MDM initiative — an organizational com- 
mitment to MDM fulfilled through multiple projects. Table 

4-1 summarizes the differences between an MDM project and 
an initiative. The MDM initiative is an essentially permanent, 
high level commitment by the business to make MDM a prior- 
ity for the improvement of its processes, and by extension, 
its financial performance. You might have multiple initiatives, 
perhaps phased in over a period of years, but each initiative 
will encompass multiple MDM projects. The initiative needs 
senior executive sponsorship and some type of organizational 
structure, such as a steering committee, to support MDM 
projects in financial and political terms. 








Table 4-1 Key Differences between an MDM 
Project and an MDM Initiative 

Factor MDM Project MDM Initiative 

Mission Achieve objectives set out Provide leadership, direc- 


in single project scope tion, and support for 
multiple MDM projects 


over the long term 


Team Line of business Senior business 
elements — stakeholders management 
IT stakeholders Senior IT management 
Project Determined byscopeand Ongoing, with regular 
cycle requirements, perhaps review and oversight 
3-6 months 
Goals Determined by scope, Based on long term 


focused on clear 
operational process 
improvements 


corporate strategy and 
operational objectives 


NBER 
ANS 
& 


MDM projects and initiatives go together. You can’t have an 
initiative without projects. And, although you can launcha 
standalone MDM project without the organizational support 
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umbrella of an MDM initiative, you will not get too far. MDM 
will only succeed if it has serious commitment from the busi- 
ness. Otherwise, you'll be fighting powerful political elements 
that may not want to allocate resources and time to what they 
consider a peripheral IT adventure. 


In our experience, the MDM initiative and its first project — 
a pilot project, if you will — tend to get started around the 
same time. Someone identifies the need for an MDM project. 
If they’ve read this book, they realize they need to have a 
broader, more senior-level initiative to provide the basis for 
success with MDM. The project creates the initiative, and 
the initiative will succeed or fail based on the quality of the 
first project. 


That said, what constitutes the right kind of MDM project to 
work on in starting an MDM initiative? Obviously, we can’t tell 
you what your first MDM project should be, but we can tell 
you a few things to look for, and to avoid, as you prepare to 
begin with MDM. Ideally, early MDM projects should have the 
following characteristics: 


Y The project goals should be clear and attainable. 
It should solve a well-known pain point in the business. 


The business processes affected should be well 
understood. 


It should avoid any unnecessary organizational strife. 


/ It should align with core IT department goals and 
processes. 


Put another way, you don’t want to declare organizational 
war in the pursuit of an MDM project for which few people 
understand the benefit. You have to plan for success with 
your early MDM projects. You can always get ambitious and 
complicated later. Start simple, get a few gratifying wins, and 
move forward! 


Revisiting the goals of PDMDM 


An MDM initiative addresses the business pain of low qual- 
ity master data through a holistic process that is intended to 
result in a number of data, IT, and business benefits, including: 
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M Optimal data quality: Data should be of high quality 
(few errors and duplicates) at the point of creation. Data 
structures and unique identifiers need to be unified, 
meaning that definitions are consistent across business 
units and core processes. Data should also be available 
as extensively as possible across the infrastructure. 


™ Continuous master data processes: Effective PDMDM 
results in optimized processes for creation and mainte- 
nance of master data and the avoidance of manual inter- 
faces and process breaks. Master data maintenance 
must be proactive. 


Defined master data responsibilities: Ownership of 
master data processes has to be clear, as does the 
organization of the master data. This master data 
organization controls data and process quality 
and assures that the people involved understand 
the processes. 


M Optimized support by IT systems: A good MDM 
program will result in a reduction in disconnects 
among systems that touch master data. It will also 
add automated workflows and tools for quality 
control and data harmonization, and ongoing master 
data governance. 


Create people awareness: In the larger organization, 
the MDM program builds knowledge that master data 
is important and that insufficient master data leads 
to inefficient value generating processes. 


The MDM Project Lifecycle 


Picking the right starting point involves understanding the 
overall lifecycle of aPDMDM project. The right project will 
appear as you get into the assessment phase and think 
through the execution and evaluation. You will need to have 
a grasp of the lifecycle before you can decide where to start. 
It’s a bit like chess, or finding a parking space at a mall — you 
have to think a few moves ahead of where you want to be. Of 
course, the process can also resemble a dog chasing its own 
tail, but we’re going to help you avoid that fate. 


As you get started with PDMDM, you have two jobs. For one 
thing, you're setting up your MDM initiative, or program. 


These materials are the copyright of John Wiley & Sons, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


Chapter 4: Like Goldilocks: Finding the “Just Right” MDM Projects 39 


Then, you’re finding the first couple of early projects to be 
executed within that initiative. Now, you may be thinking, “I 
don’t want to set up a whole initiative. I just want to test the 
waters by doing an MDM project.” That’s fine, but know that 
whether you want to start an initiative or not, you’re going 

to be setting precedents and creating a pattern for MDM at 
your organization. You're doing an initiative, even if that’s not 
your plan. 


Looking at Figure 4-1, you may be hearing a word in your mind 
that often pops up when you are presented with this kind of 
circular arrow design. That word is “consultant.” Yes, this pat- 
tern is very consultingesque (and, don’t tell anyone, but it was 
created by a consultant). And yes, you may need a consultant 
to help you get your PDMDM efforts off the ground. 


—=> Assess/ 


Evaluate Strategy 
Analysis 





Govern 
Design 





Implement 


Figure 4-1: The PDMDM project lifecycle. 


Do you really need a PDMDM consultant? That’s a question 
that only you can answer. We think that ideally, you can be 
your own best MDM consultant, though you may need some 
outside consulting expertise to get yourself started. An out- 
side consultant can also help provide an outside perspective 
and advice on how to apply MDM technology to your orga- 
nization. MDM isn’t a simple topic, so it might benefit your 
organization to get some professional advice at the beginning 
of the process. 
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MDM Assessment 


Your entry point into the PDMDM lifecycle will begin with an 
assessment. One word in the MDM assessment process has 
the magic power to enable you to select successful MDM proj- 
ects. That word is alignment. APDMDM project moves along 
five basic tracks. The more aligned these tracks are with one 
another, the better it will go. 


Before you can do an MDM assessment, you need to know 
what you're assessing — you don’t want to eat dinner before 
you look at the menu! With PDMDM, the assessment process is 
about understanding how a company’s business, processes, and 
information systems can be improved by the five project tracks 
shown in Figure 4-2. These tracks represent the actual work you 
need to do for a PDMDM project, so you have to think through 
how you will be doing it as you go through your assessment: 


M Change and transition management: A PDMDM project 
is going to involve changing the way people do things. 
Never an easy prospect, but necessary! 


Process design and organization: As the process-driven 
part of process-driven MDM implies, this kind of MDM 
is all about business processes. You’re going to need 
to understand how different processes work, how data 
relates to them, and how they will be affected by MDM. 


MDM system and IT infrastructure: MDM almost always 
requires a dedicated system of some kind. The nuts and 
bolts of managing master data can be complex. You have 
to understand how an MDM system will function in your 
environment, and how it will be affected by other IT fac- 
tors in the infrastructure. 


Master data transformation: Getting even nuttier and 
boltier, you will be examining exactly how data will change 
in the MDM process. For example, will the ZIP Code field 
have 5 digits, or 9? Will it need to include numbers and let- 
ters for international addresses? And so forth. 


Master data migration: Once transformation is under- 
stood, you have to get on top of the actual migration of the 
master data. MDM usually involves moving data from one 
database to another while cleansing it in the process. This 
migration needs to be thought through with great care. 
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Figure 4-2: The PUDMDM project process tracks. 


MDM assessment tasks 


Holding the five MDM project work tracks in mind, and brac- 
ing yourself for great alignment, you can now start your 

MDM assessment. One trick that works really well is to think 
like a consultant even though you're dealing with your own 
organization. MDM assessments benefit from trying to be 
objective and rational about what’s going on in the enterprise. 
Take a step back and consider the following aspects of MDM 
assessment: 


Corporate strategy: Start at the beginning. What is your 
business trying to accomplish, and what is its plan for 
getting there? Hint: It’s a question worth asking of senior 
management. For one thing, you might hear an answer 
that surprises you. And, you gain credibility with the 
higher-ups when you show them that your project is 
rooted in strategy. 


M Stakeholder analysis: Identify the stakeholders for MDM! 
What about MDM awareness and knowledge? What is the 
influence of specific MDM stakeholders in the corpora- 
tion? Who are the sponsors and candidates for the MDM 
project team? 
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YM Realistic objectives: Objectives need to be measurable 
and attainable. This is valid for all types of projects, but 
it is especially valid for MDM projects. To bring MDM 
stakeholders (back) down to earth, the MDM maturity 
should be assessed and the objectives should be priori- 
tized based on that. Starting with the “low-hanging fruits” 
will help to get acceptance for your first MDM project! 


External factors: Lessons learned from prior MDM proj- 
ects should be taken into account. What went wrong? 
What information can be reused in order to avoid double 
work? Also, other boundary conditions should be taken 
into account. Examples are compliance aspects, limited 
resources and budgets, or other restrictions. 


Review of organization: Who does what? Who reports to 
whom? Which part of the organization owns specific IT 
systems and databases? 


Process analysis: How do things get done at your busi- 
ness? In this piece of the assessment, it helps to focus 
on core, high-value processes. A business will invariably 
have hundreds of processes, some of which aren’t good 
candidates for MDM and should be ignored at this point. 


Key success factors (KSFs): How does the business define 
success? Obviously, profitability and share price are 
huge, but in day-to-day terms, how does the business 
know how well it’s doing? Hint: Look at how executives 
earn their bonuses. That will tell you a lot. 


/ Identification of problem areas/pain points: What is 
bothering executives about the business? What’s not 
working as it should be? Where are KSFs not being 
attained, and why? 


Meaning of master data objects and key attributes: 
Which data in the business can be identified as master 
data? How is it defined and structured? What systems 
does it touch? Where does it “live”? 


M Architecture/system interfaces: Map the overall archi- 
tecture of the enterprise, including applications that 
function in core business processes. 


Data flows: How does data move across processes and 
systems? Where does it start and end? How is it trans- 
formed through core processes? 
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M Documentation: Good documentation is critical. An 
essential deliverable is an MDM project portfolio docu- 
ment containing all possible MDM projects. It is very 
helpful to build a fact sheet for each single project con- 
taining a management summary, key resources, the proj- 
ect’s contribution to the objectives of the overall MDM 
initiative, influences on other projects listed in the road- 
map, and a rough timeline and effort estimation. 


MDM assessment methodology 


How will you figure all this out? You could rely on blind guess- 
work, but the best practice is to reach out to those who know 
the answers and ask them some specific questions. Typically, 
this is done on two levels. You can create an MDM assess- 
ment survey, which is a questionnaire that you send to a large 
number of stakeholders. For the most senior, influential, and 
knowledgeable people you need for the assessment, discuss- 
ing the questionnaire in person is the best approach. 


The final deliverable of the MDM assessment can take several 
different forms. Generally, the team charged with the assess- 
ment prepares a report summarizing its findings and presents it 
to the group responsible for the MDM initiative. The length and 
format of this report can vary greatly. Plus, you may well want 
to have two reports. One report is for public consumption. The 
other is for internal team use. This second report, which may 
actually be a collection of notes and comments, is what you use 
to make your picks for early success with MDM projects. 


Evaluating the candidates 


As you go through your assessment, you will start to see cer- 
tain possible MDM projects emerge. Some will be better fits 
than others. The best candidates will have maximum business 
impact with relatively few serious execution challenges. There 
is no perfect project, for sure. We suggest a scorecard approach 
to comparing your best candidates documented in the project 
portfolio document mentioned. The evaluation of candidates 
will lead to a prioritization or even an elimination of projects 
from the MDM project portfolio. The fact sheets will help to 
build up the MDM roadmap bringing the projects in the right 
sequence and overall timeline of the MDM initiative. 
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Shortcut: Common business initiatives 
that lend themselves to MDM 


If all of this seems like a lot of work 
(and who needs more work?), you can 
always fall back on some common 
business initiatives that are suited 
to MDM. Mergers and acquisitions 
(M&A) are staples of MDM, as is fast 
growth. Need a good MDM project? 
Search for the nearest convenient 
merger or high-growth division; you 


Another shortcut approach that 
works for identifying good MDM 
projects is to look for serious prob- 
lems in the business. Check for 
cost overruns, poor process per- 
formance, slow time to market, low 
share price, siloed departments, and 
compliance violations. Solve the 
problem by finding the MDM basis 


for it. You Know it's there. Trust us. 
You'll be a hero. 


will almost certainly find a compel- 
ling MDM situation on hand, one that 
is easier to fund because everyone 
involved is expecting to get rich from 
all the action. 





Table 4-2 shows a simplified MDM project scorecard. It com- 
pares the degree of business impact with likely challenges in 
execution. The highest scoring project candidates are ones 
with potentially high business value and relatively low execu- 
tion risk. Comparing three potential MDM projects, it enables 
you to assign a score, from 1 to 5, for how well aligned the 
project is with business strategy, how clear the related pro- 
cesses are, how easy it will be to implement the project, and 
the clarity of the KSFs. Using this method, you can quickly 
see which project is the best one. Project B is the high scorer, 
though it suffers from poor process clarity. Not a big deal, 
however. You can fix those processes in the project itself! 
Project A is a suicide mission — a tough project with little 
demonstrable business value. Project C is a meaningless slam 
dunk. It will be easy to do but will not give you much in the 
way of business bragging rights. 
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Table 4-2 MDM Project Scorecard 


Project Strategy Clarity of Ease of Clarity Total 
alignment processes PDMDM of 
execution KSFs 





Strategy, Process MD objects, KSFs, 

Organization analysis system pain 
interfaces, points 
architecture, 


data flows 
ProjectA 2 1 1 1 5 
Project B 4 2 5 2 14 
Project C 1 4 4 1 10 


When selecting your first MDM project, it can be tempting 

to reach for the stars. You should fight this temptation and 
instead focus on a project that can show concrete value. As 
we discussed at the start of this chapter, you don’t need to 
declare organizational war to start making progress in improv- 
ing your organization’s data and processes. As the value of 
MDM gains more credibility in your organization and you gain 
more experience with MDM, you can start to consider the 
harder challenges. 


These materials are the copyright of John Wiley & Sons, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


ho Process-Driven Master Data Management For Dummies 


These materials are the copyright of John Wiley & Sons, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


Chapter 5 


Weed Whacking Time: 
Planning and Designing 
Your First MDM Solution 


In This Chapter 


Going into detail on the execution of an MDM project 


Understanding the IT system and architectural aspects of PDMDM 


T°: moment has arrived to stop theorizing and start get- 
ting real. The goal of this chapter is to show you how an 
actual MDM project might be implemented in a real business. 
Starting with a process that is inherently broken from an 
MDM perspective, you will see how to get clean master data 
for ongoing use. 


A larger organization’s first MDM implementation may be 
just one of many that, ideally, is part of an overall MDM pro- 
gram. Consider the MDM program as a “lifestyle” way of man- 
aging your master data, different from how it used to be done 
previously. 


Analyzing the Problem 


PDMDM begins and ends with processes. Processes run on 
data. Data is the primary input (with human help) into a pro- 
cess, and each process step creates its own data that flows to 
the next step and beyond. Good quality master data enables 
effective business processes, though the opposite is also true. 
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A tire manufacturer has identified a process that is particu- 
larly harmful to master data in its business. The process in 
question, depicted in Figure 5-1, shows how the manufacturer 
discontinues old products across three systems. As a manual 
process that is prone to cause master data irregularities, it is 
a great candidate for PDMDM. 


Sales and Marketing Systems 


CRM App 


Dacidate Change status of Created report of — 
di Gane discontinued tires to discontinued tires Distribute the Se 
Iscont Discontinued the DC Report DC Report 
tire in sales database Sales Database 


Distribution and Warehouse __ 
Add Comment Logistics App 
that tire is 


~~) discontinued in ee 
inventory database Inventory 
Database 
Factory 
Delete SKU from ERP App 


—| manufacturing nes: 
database 
Factory 
Database 


Figure 5-1: The existing process for updating the three separate databases 
that carry product information at the tire manufacturer. 





The sales department, based on input from senior execu- 
tives, decides which tires are going to be discontinued. The 
sales department changes the Status field of the product to 
Discontinued. Salespeople will no longer sell the tire when the 
product has been marked Discontinued. The sales department 
regularly creates a report that tells the factory and warehouse 
which products have been discontinued. Those departments 
then update their respective systems and databases. The 
logistics application that runs the warehouse doesn’t have 

a Status field for the product, so the discontinued status 

is noted in the Comments field of the product listing. The 
factory, though, simply deletes the product. They’re not 
making it any longer so they don’t need it anywhere. 


Can you see the potential for master data problems in this 
process? For one thing, the process is manual and slow. At 
the very least, it presents a risk that a product will be discon- 
tinued in the sales department but accidentally not discontin- 
ued from the warehouse or factory. The process creates three 
similar but not identical product databases. These separate 
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processes cause costly errors in order management, espe- 
cially in situations where products are being returned. The 
warehouse might receive a defective product back and prom- 
ise to replace it, only to find out later that the product has 
been discontinued. This creates extra work and confusion. 


Discovering the relevant 
master data 


The first step in addressing the problem is to discover what 
the relevant master data actually is in the process. In this 
case, it is product data or product records. Then, you have 

to understand what attributes of that data are relevant to the 
process, for example the SKU number and product status. 
After that, you can model a master data object that represents 
how you understand the master data to be created, modified, 
and deleted during the process. 


In the old fashioned data-focused MDM approach, it can take 
a long time to get everyone to agree on such models. But 
PDMDM provides the business context needed to quickly 
come to agreement around what master data is relevant and 
how it should be modeled. 


In the discontinued tire example, the master data object 
would be a defined schema (which is configured within the 
MDM tool) for a parts or SKU master prescribing the set of 
fields defining a parts master (and allowed relationships to 
other data objects). The record of the tire product contained 
in the master data system is an instance of the parts or SKU 
master. For instance, a truck tire would have different char- 
acteristics/field values compared to a tire for a compact car, 
but both will be maintained based on the same parts or SKU 
master. The parts master record would hold at least the one 
undisputed product SKU number, a short text, some dimen- 
sions (diameter/width/weight), and product status. 


The target solution 


The Discontinue Tire process takes a new form when you use 
PDMDM. The tire company will still discontinue the tire, but 
with a different, more efficient, process. As Figure 5-2 shows, 
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the target process is now simpler and more automated. When 
the sales and marketing database is updated, indicating that 
a tire’s status has been changed to Discontinued, this change 
flows automatically through a master data object in the MDM 
system. When someone looks up that tire’s SKU in the dis- 
tribution or factory systems, the tire will show a status of 
Discontinued. 


Sales and Marketing 


Change status of 
discontinued tires to 
Discontinued 
in sales database 


Decide to 
discontinue 
tire 


Distribution and Warehouse = 
Logistics App 


Change status of 


discontinued tires to ae 
Discontinued in Master 
inventory database oe | Net | 
Factory 
Change status of ERP App 


discontinued tires to 
Discontinued in ee 
factory database Factory 
Database 


Figure 5-2: Target process and solution architecture for PDMDM atthe tire 
manufacturer in the case of “Discontinue Product.” 





“Wait a minute!” you might be saying right now if you’ve been 
paying attention. How do the factory and distribution data- 
bases show status? The answer is that with the change in 
process, they now can. Making the master data system work 
with the master data objects often involves redoing the basic 
data structure of fields in the database record. This is just one 
of many changes that need to take place at the process and 
system level as you realize PDMDM. 


Overview of Solution 
Components 


First, be clear up front about your MDM objectives and your 
MDM strategy (see Figure 5-3). The process-driven approach 
that we have elaborated on in earlier chapters should help 
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identify and clarify your objectives and high level require- 
ments. Your MDM strategy will help answer questions such as 
the following: 


™ How intrusive to your current system landscape and 
business processes can/will the MDM solution be? 


M Will the master data be used by core business processes 
in operational systems, or consolidated for a “single 
view” use case, post-operationally? 


What is the scope and what are the subject areas to be 
included in this first iteration? 


MDM Strategy 


MDM Objectives 


YY 


MDM Solution Components Program Management 
MDM Architecture 
Principles 
Solution Design 
Technical Data 
Architecture Architecture 


- Style 

- Interfaces 

- Technology 
evaluation 


- Executive sponsorship 


- Organization 






- Metrics and ROI 





- Data modeling 

- Governance 
policies 

- Stewardship 
rules 





Figure 5-3: A look at solution components for MDM. 


MDM architecture principles will guide your overall architec- 
ture. These principles answer questions such as: 


Which of your systems is the owner of specific master 
data entities? 


M Where should certain master data be created, or should 
that master data be consolidated from multiple systems? 
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YM What should the ongoing governance process be for 
master data in order to ensure ongoing data quality? 


YM What will be the single point of deployment for master 
data? 


Your MDM objectives, strategy, and architecture principles 
together will help you determine your MDM solution design. 


Your solution design has two components, technical archi- 
tecture and data architecture, which are discussed in subse- 
quent sections. Finally, your infrastructure architecture will 
support your overall MDM solution by providing the essential 
hardware and system software components, such as the data- 
base and application server platform. 


Technical Architecture 


MDM technical architecture includes the topics of MDM 
architectural styles, integration and interfaces, and technol- 
ogy evaluation. 


MDM architectural styles 


A key facet of your solution is the architectural style of MDM 
that you will adopt. MDM styles have evolved over the past 
few years, to the point where there are now a few generally 
accepted ones. Figure 5-4 shows the six common styles. 


Consolidation Registry Coexistence 


—— 


Centralized 


des 





J Represents where data is authored. 11, 12: transactional systems. MDM-Hub: system of gold record. 


Figure 5-4: Common architectural styles for MDM solutions 
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Which style you use will depend on factors such as the master 
data domains or subject areas being managed, the functional 
requirements, the current system landscape, and how intru- 
sive you can afford to be with systems and processes and 
performance requirements, as well as more general condi- 
tions such as the industry you are in and the business type: 
whether business-to-business (B2B), business-to-consumer 
(B2C), and so on. 


The following are the prevalent styles visualized in Figure 5-4: 


™ Consolidation: Master data is authored (created, updated, 
deleted) in several transactional systems (denoted by T1 
and T2) and consolidated into the MDM Hub as the Golden 
Record. Matching, merging, and cleansing of data are done 
within the MDM Hub. Master data is not entered directly 
in the MDM Hub, and it is not written back to the transac- 
tional systems. 


M Centralized: Master data is authored and governed cen- 
trally within the MDM Hub and deployed to other systems 
in your landscape. 


Registry: In this style, data authoring is done within trans- 
actional systems. Master data isn’t moved to the MDM 
Hub; instead, the hub stores pointers to the master data 
which continue to remain in the transactional systems, in 
order to identify the record in the transactional systems. 


M Hybrid: Master data authoring can be done in the trans- 
actional systems as well as in the MDM Hub. Sanitized 
master data can be written back to transactional systems. 


Coexistence: Master data is entered in transactional 
systems only. After utilizing an MDM Hub as a kind of 
Data Quality Service, sanitized master data can be writ- 
ten back to the original transactional system as well as 
being distributed to other transactional systems. This 
integration style is usually established when a central- 
ized approach isn’t feasible because historically several 
data hubs have been established. 


M Central Deployment Hub: In this scenario, master data 
from a source is taken as it is (single source of truth, 
also previously known as Dominant Source). The master 
data may be enriched and then distributed to various 
other systems. 
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One style isn’t necessarily better than another; it’s just that 
one might be better suited to certain circumstances than 
others. For example, in a business where multiple systems 
need access to identical master data in split-second, real-time 
transactions (which might be the case in banking), a non- 
centralized approach may not work. In addition, what already 
exists in the infrastructure must be taken into account. For 
example, if one system enjoys the bulk of institutional sup- 
port and has the biggest complement of fully trained DBAs, 
then that would be a logical leading system (Scenario: Central 
Deployment Hub). This scenario can be found when a com- 
pany has made a big investment in a given ERP and financial 
suite. That is where the expertise will be. Usually many data 
have already passed internal approval processes, and there- 
fore, you don’t have the pressure to break these processes 
apart short term. As you’re planning which architecture to 
use, consider the impacted business processes and existing 
IT system to select the best MDM architecture. 


Integration and interfaces 


There can be a lot of moving around of master data to build 
your MDM solution. Data may also need to be transformed 

as it makes its way into the master data repository, in some 
cases from systems, applications, and databases that are very 
different from the master data system. 


You need to consider both your real-time interface needs as 
well as batch interfaces. Today, numerous options abound 
when it comes to integrating your MDM solution with your 
enterprise systems, ranging from the simpler point-to-point 
direct interface between systems to a messaging-based 
Enterprise Service Bus approach. Other options include using 
an Extract—Transform—Load (ETL) or Web Services. Your cur- 
rent and desired system landscape will be a major determi- 
nant of what sort of interfaces you use in your MDM solution. 


Does it matter that the systems involved may be built on dif- 
ferent platforms and databases? Yes and no. Although XML 
technology vastly simplifies the process of communication 
between different types of systems, it addresses mostly the 
mechanics of exchanging data. Conflicts in definition and 
meaning among systems can still cause challenges. As you 
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plan and oversee the migration and transformation of data, 
you will have to be aware of potential cross-platform issues. 


Technology evaluation 


When it comes to selecting the technology pieces for your 
MDM solution, you have a number of choices, which means 
you have several decisions to make. An early decision would 
be whether to build a solution using in-house and possibly 
external resources, or buy a vendor product. 


Over the years, as MDM has become an established disci- 
pline, vendor offerings have, in general, matured quite well. 
However, there may be valid reasons for an organization to 
develop its own MDM solution, such as having a unique set 
of needs that vendors are unable to meet without extensive 
product customizations, or if they already possess many of 
the technology pieces and have the expertise to roll out a 
complete solution. However, keep in mind that your MDM 
requirements are likely to change as the business environ- 
ment inevitably changes, and custom-developed solutions 
are typically not designed with future flexibility in mind. Plus, 
you ll need to maintain the solution on an ongoing basis. 


If you do decide to go with buying a vendor product, that 
opens up another set of decision points. Should you select 

a single vendor who will provide all the pieces to your MDM 
puzzle, or go in for a best-of-breed approach possibly includ- 
ing multiple vendors to cover specialized areas? In addition 

to core MDM functionality, you will need to address, at a 
minimum, the areas of data quality, ETL, and messaging. 
Additionally, you may want to investigate whether you need 
tools such as a specialized workflow or business process man- 
agement engine, external authentication, and so on. 


Remember that MDM is a long-haul journey with many 
unknowns lurking in the future. So the best decision may be to 
pick an end-to-end configurable platform that is also modular 
and pluggable. What this means is that you should have the 
ability to roll out a complete solution with the core MDM tech- 
nology you choose. And at the same time, you should have 
the option to plug in pieces and parts you already own. For 
example, you may already be using an ETL or reporting tool in 
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service of other data management initiatives. A modular and 
pluggable MDM platform will give you the option of using your 
existing ETL and reporting tools. 


Data Architecture 


The data architecture component of the MDM solution includes 
several key pieces, such as the data model to be used in the 
solution, data quality, and data governance. Data modeling and 
data quality are well-developed and mature disciplines with 
established practices and rules, and data governance is a topic 
that has recently seen significant industry interest and focus. 


Broadly, there are two approaches to data modeling when 

it comes to MDM solutions. You could go with a proprietary 
data model that is built into the solution, or use an open data 
model that you design yourself and which will become part of 
the solution. 


Data quality is a specialized topic in itself and can vary quite 
a bit depending on the subject area of the MDM solution. For 
instance, in an MDM solution for customer information, the 
data quality engine would include components for standard- 
izing name and address and validating addresses against 
postal directories. A data quality engine of product data could 
include technology for parsing strings to recognize product 
names and fields. 


Data governance may include quality rules, enforcement, and 
enrichment of fields. Governance can be active or passive; the 
former tries to prevent the wrong data being entered, whereas 
the latter reports on errors after the fact. 


Program Management and 
Change Management 


MDM projects, depending on scope, can alter the way a com- 
pany’s business processes are run. A formal MDM program 
management effort is necessary to ensure success, which 
should ensure that: 
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M The right charter is in place that addresses core require- 
ments. The charter should address the objectives and 
high level requirements, as well as outline a plan to 
accomplish them. 


M The right sponsors are on board to guide and support 
the program. As an MDM initiative is cross-functional 
and affects multiple departments, its long-term success 
is very much dependent on obtaining executive spon- 
sorship at the highest levels, right from the beginning. 
Otherwise, failure is almost a certainty. 


M An appropriately staffed team is in place. This can 
include the usual roles in any IT project, such as project 
managers, business analysts, data architects, database 
administrators, technology specialists, and so on. Specific 
to MDM projects, you have to define master data respon- 
sibility. Every data item will have an owner. In the case of 
the discontinued tire, there are at least three owners, cor- 
responding to the three systems that contain tire product 
information. The three owners of tire product data need 
to agree on who will own the responsibility for the tire 
product master data. This is the role of the data steward, 
typically someone from the business who understands 
the importance of the data item under question. 


M The program and individual projects are proceeding on 
track. It is important to show early and quick wins using 
objective metrics to prove that MDM brings real benefits 
to the organization. 


There’s an old joke that goes, “How many psychoanalysts 
does it take to change a light bulb?” The answer: “One, but 
the bulb has to want to change.” It’s funny but it’s also true. 
Change only occurs when people want it — or at least are 
presented with a reasonable way to make it happen. PDMDM 
is about making changes, a process that itself must be man- 
aged. What changes in the Discontinued Tire example? A lot, 
it turns out: 


The process: You’re reworking the process, chang- 
ing from a semi-manual process to one that is largely 
automated. This change involves building new system- 
to-system connections and eliminating several manual 
processes. 
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The data fields: The structure of the data itself has to 
change to create the new process. Now, each database 
contains a field for Status so that each operating data- 
base has the same status reference. 


The systems: A new MDM system is added to manage 
the master data objects. Connections must be created 
between that new MDM system and the operating 
databases. 


The ownership of certain tasks and processes: The 
people doing the work also have to change the way they 
do things. This may or may not be a big deal, depend- 
ing on the organization and other factors, but it must be 
addressed. 


This last point is worth underscoring. When we talk about 
PDMDM we tend to think about it in technology terms, and 

it is largely a matter of technology. However, when you start 
changing processes, even ones that are completely auto- 
mated, you invariably change the workaday routines of the 
people involved. As you may have found, people don’t gener- 
ally like change in the workplace (to be understated about it). 
Some consultants specialize in change management, and you 
may want to bring that kind of resource to bear on your MDM 
initiative. To enjoy a successful adoption of the MDM project, 
you have to engage with the people who will be affected by 
the changes wrought by the initiative. 
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Chapter 6 


Cha-Ching! Bottom Lining 
MDM and Engaging with 
Business Stakeholders 


In This Chapter 


Discussing how to align MDM with corporate strategy 
Making the case for MDM to business stakeholders 


Understanding data governance 


M DM is about money. Like it or not, any serious discus- 
sion about master data management is going to lead 

to a business person asking, “Why should we spend money 

on this?” It may be an annoying question — we all expect our 
ideas to be funded without any questioning — but it’s a fair 
thing to ask. There’s only one reason to invest in MDM, and 
that is if the program will help the business make more money 
or become more valuable. Pick one, or both. Earn more. Be 
worth more. 


Aligning MDM with 
Corporate Strategy 


MDM needs to be aligned with strategy. Of course! But, what 
exactly is strategy? Think of strategy as direction-setting ideas 
and decisions that are meant to make a business more profit- 
able and valuable. Remember, business is about earning more 
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and being worth more. Strategy, therefore, is about figuring 
out the path from the present to the high-earning, highly 
valued future. 


geniBeR The goal of business strategy is almost always to situate the 

© business in a sustainably profitable place. For example, if a 
business can achieve a uniquely low cost structure over the 
long term, that will result in sustainable high profits and an 
attendant rise in valuation. The pursuit of that low cost struc- 
ture would be the company’s strategy. Realizing that strategy, 
though, is an operational issue, one that is deeply enmeshed 
with IT and MDM. 


Figure 6-1 shows the master data strategy implications for 

a chemical company that has a vision of being the preferred 
world leader. Being the preferred world leader means that the 
company can earn consistently high margins by out-delivering 
its competitors on multiple fronts. To get there, the company 
has set itself a mission of offering distinctive, high-quality 
products and services, backed by optimum utilization of 
human and natural resources and state-of-the-art technology. 


Strategy Alignment Project example 


Vicon Master Data Strategy Implications 


To be the prefarred world @ Facilitate quicker decision-making 
leader in chemicals Rapid Visibility of shared customers, vendors, materials, 
growth etc. across multiple locations, business units 
and affiliates 
Multi-dimensional data views 


Defined governance to coordinate responsibilities 


Mission = Information at the desired level 


istincti igh- i Aggregation and drill-down at geographic 
othe eae Sik Global | (local, regional or global), functional, or business 
Uo ahieee expansion unit levels 


Harmonized data model 


Optimum utilization of our Consistent data hierarchies 
available human and natural 


resources = Provide transparency 
Standardized data for easier comparability of 
State-of-the-art technology Increased performance 


complexity . 
Safe and environmentally Single data dictionary 
sound practices Common data management processes 
@ Flexibility to add / remove master data 
Easy integration of acquisitions, business units, 
Specialty products (and removal of divested business 
expansion units etc.) 
Defined roles and responsibilites 
Support for multiple data sources 





Figure 6-1: Alignment of business strategy with MDM. 


MDM is a key factor in realizing this company’s vision and 
mission. Becoming the preferred world leader involves being 
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able to make the right management decisions, quickly, across 
multiple geographies and organizational layers. This is a data 
and IT issue. An effective MDM program will give the chemical 
company visibility of shared customers, vendors, materials, 
and so forth. It makes information available at the desired 
level, with consistent hierarchies so that managers can drill 
down and understand business conditions clearly. These 
capabilities are built on a foundation of defined roles and 
strong data governance. Without this kind of MDM effort, the 
company runs the risk of performing sub-optimally and conse- 
quently losing its leadership position in the market. 


Making the Case for MDM 
to Business Stakeholders 


Why do you need to make the case for MDM to business 
stakeholders? Shouldn’t you just dazzle them with your bril- 
liance and have them shower you with funds? Ah, if only. The 
reality in a business is that you have to make a persuasive 
argument for MDM — or any other worthwhile initiative — 
that will resonate with needs and agendas at multiple levels of 
the organization. 


The key concept to grasp here is that funding for an MDM ini- 
tiative must compete with other projects that may appear to 
be equally (or even more) compelling to senior management. 
Assuming that funds are limited (and if you’re at a place where 
they’re not, please contact us as soon as you can) the question 
for top executives is always, “What should get priority invest- 
ment?” Should they retool a plant, or do MDM? Should they 
invest in social media marketing, or do MDM? Invest in R&D 

or MDM? MDM has to seem like a better bet than a lot of 

other very good ideas. 


goiiBEn You're going to get involved in serious corporate politics if 
Y you re trying to get MDM off the ground. Even inside the IT 
Cj} organization, MDM may not fare well if you can’t equip senior 
IT executives to advocate for it at the C-level of the corpora- 
tion. Remember, the CIO and CTO usually need to justify their 
budget to the CEO and CFO. Alternatively, they may need to 
fight back against pressure to cut the IT budget. If MDM can’t 
appeal to a broad range of business stakeholders and is seen 
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as an optional program, it could easily end up on the 
chopping block. 


The challenge is to craft a message to each major stakeholder 
group that positions MDM as an essential factor in getting 
their respective jobs done better. Table 6-1 identifies several 
basic ways to connect MDM with the business-critical func- 
tions of several groups. At the Strategic Business Unit (SBU) 
level, the people in charge are responsible for business plans 
and results. Indeed, their compensation is likely tied to how 
well they can plan and execute. SBU leaders and their teams 
need to be able to forecast sales, create marketing plans, and 
develop pricing strategies. They’re also typically on the hook 
for inventory and production management, even if it is out- 
sourced. To make MDM appealing to this group, you need to 
show how MDM will help them gain an edge in customer focus 
and competitive brand strategies, and help perform their 
tasks better and faster. The better the data, the better the 
plan and the post-plan analytics will be. 





Table 6-1 MDM's Benefit for Major Business 


Stakeholder Groups 
Stakeholders Business Critical Other Benefits of 
Functions Stakeholders MDM 
Impacted 
CEG Shareholder Shareholders Accurate 
and market and regulators reporting of 
announcements financial results 
SBUs/ 
Regulatory functions Maintain 
and auditor regulatory 
requirements compliance 
Business plan Increase in 
and growth stakeholder 
targets confidence 
Increase in 
transparency 


and governance 
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Stakeholders Business Critical 


SBU EVPs, 
GMs, and 
Teams 


Finance 


Functions 


Strategic busi- 
ness unit plan 
and results 


Developing 
sales report and 
forecasts 


Creating market- 
ing plans 


Developing pric- 
ing strategies 


Inventory and 
warehouse 
management 


Production 
management 


Reporting (finan- 
cial, manage- 
ment, and so on) 


Month end 
closing and 
reconciliations 


Budgeting and 
forecasting, 
planning 


Finance and 


accounting (F&A) 


management 


Other 
Stakeholders 
Impacted 


SBUs/ 
Functions 


CEO 


Shareholders 
and regulators 


SBUs/ 
functions 
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Benefits of 
MDM 


Increased 
advanced data 
analytics 
capabilities 


Aids in creation 
of competitive 
brand 
strategies 


Enables better 
customer focus 


Reduces errors 
In inventory 
levels 


Enables SLA 
achievement 


Accurate 
reporting 


Reduced errors 
In day to day 
operations 


Increase in 
overall func- 
tional efficiency 


Increase In 
stakeholder 
confidence 


(continued ) 


These materials are the copyright of John Wiley & Sons, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


64 Process-Driven Master Data Management For Dummies 


ar 





Table 6-1 (continued) 





Stakeholders Business Critical Other Benefits of 
Functions Stakeholders MDM 
Spat 
Global Category SBUs/ Increased ana- 
Procurement management functions lytical abilities 
Sourcing Enhanced 
category 
Spend analysis management 


management Development of 


better procure- 
ment strategies 


Success in this process involves getting inside the head of 
your target stakeholders. (Be careful. You might find yourself 
coveting a Rolex.) Think about what matters to a given stake- 
holder group. That is where the value of MDM needs to be 
emphasized. In particular, try to frame the value in terms of 
how the benefit of MDM relates to stakeholder interaction and 
reporting relationships. For example, the General Manager 

of an SBU operating area, such as sales, will be keenly aware 
of how his or her performance affects the overall SBU perfor- 
mance. How can MDM have a positive impact on that func- 
tional area? That impact will be the basis for approval of MDM 
from that stakeholder. 


You will not be able to develop an argument for every influ- 
ential stakeholder in the organization. However, if you can 
identity those with the proper pull, you need to hit them with 
a point of view that speaks directly to their daily concerns. 
This is where the “P” in PDMDM is most helpful. Discussions 
with business stakeholders should involve the processes and 
performance indicators that are meaningful to their work. 
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Identifying Which KPls 
Will Be Affected 


A KPI is a key performance indicator. All businesses have 
them, and every department will have its own as well. KPIs 
are quantitative data points that describe how well a business 
is doing. They include earnings per share, revenue growth per 
quarter, percentage of orders returned, and so forth. If you’re 
not sure which KPIs are important to your business, just 
listen for that weird acronym that everyone is sweating about. 
People will be in the cafeteria wringing their hands about the 
CROIC (cash return on invested capital) and EBIT (earnings 
before interest and taxes). 


KPIs are what matter to influential people. Executives live and 
die by KPIs. Successfully attaining a KPI can mean a raise and 
a promotion, though of course the opposite is also true. As 
part of your effort to get to the bottom line about MDM and 
get the support you need, you have to frame the conversation 
in terms of KPIs that matter to the stakeholder in question. 
This may require some research. 


Risk Management as 
a Driver of MDM 


Don’t get us wrong. Engaging with business stakeholders is 
about far more than just getting funded. An effective PDMDM 
program will result in ongoing success and value creation. 
We've already touched on operational results and value 
creation as two main drivers of engagement with business 
leaders. A third driver, risk management, also deserves atten- 
tion at this point. Risk management is a serious subject for 
many stakeholders. The management of risk is the specific 
work of certain people in an organization, such as the Chief 
Compliance Officer. However, many other executives are 
implicitly tasked with risk management. 
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Risk management is a broad discipline that spans information 
security, financial controls, regulatory compliance, and opera- 
tions. That can of toxic paint thinner in the janitor closet? 
Risk management. The Sarbanes Oxley Act? Risk management. 
Extending too much credit? Risk management. However, risk 
management is always about the same thing, which is pro- 
tecting assets bought with shareholder money from the risk 
of loss. The executives of a company have a duty to protect 
shareholder assets from theft, misuse, waste, unsound busi- 
ness practices, and so on. A big part of senior leadership’s job 
is to shield assets from risk. 


What almost every form of risk management also has in 
common is data. Managing risk is almost always about being 
aware of risk (for instance, information about risk) and track- 
ing data on how well it’s being managed. Given the impor- 
tance of data in risk management, it makes sense that MDM 
can have a big impact on how well risk is measured and man- 
aged in an enterprise. 


Table 6-2 lays out the four main types of risk and aligns them 
with some core areas of MDM focus. For example, financial 
risk, which has to do with a company’s ability to correctly 
record financial performance, can be affected by problems in 
transaction data. In turn, data related to materials, customers, 
and vendors impacts financial risk management. Tight, high- 
integrity master data related to materials used in production, 
and to some extent vendor data, is critical to ensuring proper 
financial reporting. In this way, MDM enables management of 
financial risk. 


Engaging with business stakeholders using risk management 
as a driver of MDM shows that you “get it” when it comes 

to the role of data in business management. The approach 
shown in Table 6-2 further demonstrates that you understand 
that some data is more relevant in the risk management 
process. 


These materials are the copyright of John Wiley & Sons, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


Table 6-2 


Risk 
Category 


Description 


Potential 
Causes 
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The Four Main Types of Risk and the 
Impact of MDM on Managing Them 


Financial 
Risk 


Affects 
company's 
ability to 
correctly 
record 
financial 
perfor- 
mance (for 
instance, 
revenue, 
costs, 
assets, lia- 
bilities, cash 
flow) of 
processed 
transactions 


Incorrect 
bill-to 
customer 
codes 


Incorrect 
customer 
billing 
address for 
hardcopy 
invoices 


Operating 
Risk 


Affects 
company's 
ability to 
execute 
business 
transac- 
tions (for 
instance, 
shipments, 
INVOICeS, 
payments) 
on behalf of 
its custom- 
ers and/or 
suppliers 


Incorrect 
BOM/recipe 


Incorrect 
customer 
shipping 
address 


Incorrect 
supplier 
remit- 
tance EFT 
account 
number 


Security 
and Controls 
Risk 

Risks 
related to 
the inability 
to correctly 
assign 
security 
roles (for 
instance, 
segregation 
of duties) 


Inability to 
separate 
master data 
rights from 
transaction 
authoriza- 
tions in 
user role 
definitions 


Inability 
to provide 
adequate 
controls 
in Excel- 
based 
solutions 


Regulatory 
Risk 


Affects 
company's 
ability to 
report 
accurate 
information 
to regula- 
tors ona 
timely basis 


Affects 
company's 
ability 

to meet 
Sarbanes- 
Oxley 
requirements 


Products 
that have 
shipped but 
for which 
no revenue 
or A/R 

has been 
recognized 


Process 
is not well 
documented 


Changes 
are not 
documented 
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Understanding Data Governance 


Having articulated MDM’s alignment with corporate strategy, 
made the business case for MDM, identified KPIs, and talked 
about risk management, the final point to make involves data 
governance. The processes that touch data need to be gov- 
erned just like any other important aspect of a business. Like 
risk management, the concept of data governance can be a 
bit amorphous, but it flows from the complete conversation 
we ve been undertaking in this chapter. It goes like this: If you 
want MDM to support strategy, help realize KPIs, and help 
mitigate risk, you will need to govern the data involved in the 
associated business processes. 


Governance is, as its name suggests, about controlling activi- 
ties with rules and accountability to ensure that desired out- 
comes are achieved. Corporate governance, which sits atop 
all other forms of governance, is a matter of directing the 
officers of a business to undertake processes and implement 
controls to generate a return on shareholder assets. Data gov- 
ernance is part of that overall governance process. 


Remember, data is an asset, just like inventory, real estate, 
or patents. Unfortunately, data quality tends to go down over 
time. People move. Products change. Vendors shift their SKU 
numbers, and so on. After a while, that data isn’t in good 
shape, and it’s not contributing as much to earnings or 
valuation as it once was. And, it may be elevating risk. 


The solution to this problem is to devise and implement data 
governance. Data governance is a bit like ongoing quality 
assurance for data used in the enterprise. It sets out policies 
for assuring high quality data, policies that are referenced as 
processes and systems evolve. The result is a consistent level 
of data quality. 


PDMDM is a great way to effect data governance, as it pro- 
vides the basis for defining and enforcing data governance 
policies within critical business processes. Figure 6-2 shows 
the data governance cycle, which begins with policy defini- 
tions and continues through implementation and monitoring. 
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Define Data 
Governance Policies 
and Metrics 


Implement policies 





Monitor and enforce 
policies, inform revision 
of policies. 


Figure 6-2: Data governance as a cycle of policy definition, 
implementation, and monitoring. 


To understand the connection between PDMDM and data 
governance in this cycle, think about how you would devise 
a policy to keep customer name and address data consistent. 
This policy would apply to all process automation, work- 
flows, and system integration. For example, if you wanted 

all addresses to have the ZIP+4 Code instead of just a 5 digit 
ZIP Code, you would have to specify that in the policy. Then, 
using PDMDM tools, you could implement that policy and 
make sure that any address data used in the enterprise would 
at least have the potential to record the 9 digit ZIP Code. 
Business intelligence (BI) systems would provide a mecha- 
nism to monitor the data governance. 


Data governance as implemented through PDMDM also pro- 
vides the basis for managing data incidents. A data incident is 
a situation where data may be compromised through an acci- 
dental or malicious act. In order to respond to the incident, 
database administrators need to have the necessary policies 
in place to know how to reconstruct the data that has been 
affected. PDMDM provides these policies. 
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Chapter 7 


Keeping It Cool with Your 
ClO: PDMDM and IT 


In This Chapter 


Understanding what technology is needed to support PDMDM 
Using SOA as a secret enabler for MDM 


I: actual development and implementation of PDMDM 
reminds us of the game Othello, whose tagline is “A 
minute to learn. A lifetime to master.” There is a massive 
volume of detail and nuance to absorb in understanding 
exactly how PDMDM will work at your organization. From our 
perspective, though, you really only need to understand the 
key points and the rest will flow naturally as you engage with 
professionals and acquire the right tools for the job. 


Thinkin’ Gits and Bytes: 
Technology for 


Process-Driven MDM 


PDMDM is a fusion between people (MDM dimensions orga- 
nization and culture), process (MDM dimensions BPM and 
governance), and technology (MDM dimensions data and 

IT architecture). All three elements have to be in alignment 
for PDMDM to generate the desired results. It’s a lot to hold 
together, so the trick is to assemble the right tools and con- 
nect them with people and systems in an intelligent, manage- 
able way. 
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Figure 7-1 provides an overview of the total PDMDM environ- 
ment. It shows the different components and processes that 
have to be unified in order for PDMDM to work. The busi- 
ness model, depicted on the far left, is what drives the entire 
approach. What’s actually happening at the business level 
that requires IT systems for support? That’s where MDM is 
critical. The business model drives two supporting models: 
the process model and the data model. Think of the relation- 
ship between these three models like this. The business 
model says, “Ship an order to a customer.” The process model 
says, “Oh, you mean, invoke the Ship function on the logistics 
system.” The data model says, “Right, but when you invoke 
that Ship function, use the data that I tell you to.” 


(Process Model | Process Execution 
~ 3 . SSS Ss Face eng Zeasee ss ——— a 














| Master Data} 


Figure 7-1: The complete PPMDM environment, spanning business models, 
data models, process models, the MDM system, and the actual 
process execution. 





The big question then, of course, is “Which data?” The master 
data! As Figure 7-1 shows, the actual process execution, where 
that Ship function would really be occurring, relies on the 
MDM solution to make sure that it is using the correct data for 
the transaction. The MDM solution, shown in the lower right, 
reconciles the data being used in the transaction with the 
master data object. It cleanses inbound and outbound data 
from the connected systems and makes sure that the data is 
being properly governed. 
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The C10 talk 


Behind each element shown in Figure 7-1 is a person, or 
people, and you will need to get on the same page with these 
people if you want your PDMDM initiative to succeed. A lot 
of these people are in the IT department. You’re going to find 
yourself talking to the CIO, or someone close to him or her. 


The CIO is probably going to be interested in PDMDM and 
become a champion for the idea. However, the CIO will also 
mostly likely want to be sure that your MDM project will mesh 
with the way other serious IT programs are run. These recom- 
mendations include: 


Make sure that MDM doesn’t disrupt IT operations or 
infrastructure: When you do PDMDM, you're stepping 
onto a fast moving train known as corporate information 
systems. There’s a lot of important stuff going on 
in those systems, so whatever you’re doing with PDMDM 
can’t cause problems for existing transactions and data 
processing. 


/ Be cost conscious: Think through your budget impact 
carefully. For example, will PDMDM require replacement 
of business modeling tools that have already been paid 
for? If so, you need to be able to justify the cost. 


/ Fit with security policies: Any time you start connect- 
ing systems and moving data around, you’re potentially 
exposing the organization to security risks. PDMDM will 
have to conform to security policies. For example, when 
data travels from a database to the MDM system, it may 
need to be encrypted. 


Having the right tools 


The right tool can make a big difference when it comes to 
achieving the goals of your PDMDM initiative while supporting 
the CIO’s requirements. The five elements shown in Figure 7-1 
all have to dance together in a coordinated ballet of PDMDM. 
You wonder, then, “How on earth will all of these components, 
models, and processes interoperate like this?” The answer is 
that you need tools that are designed with the whole PUPMDM 
approach in mind. Given the standard disclaimer that a tool 
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is only as good as its user, some MDM tools are better than 
others. Here are some desirable characteristics for MDM 
tools: 


Be flexible: The MDM tools need to be flexible enough 
to adapt to your immediate as well as foreseeable needs, 
and to different architectural approaches to MDM, data 
modeling, and process modeling. 


Play nicely with others: MDM tools have to interoperate 
easily with multiple types of systems and development 
environments. 


Support SOA: Service Oriented Architecture (SOA) is 
the means by which all the integration inherent in MDM 
takes place. The MDM tool needs to be compatible with 
an SOA approach to system interoperation. 


™ Connect business analysis with business process, appli- 
cation development, and data: There must be a fluid, 
automatic transition from managing the business model, 
process, and data models to the actual applications 
supported by PDMDM. The right MDM tooling will 
enable this kind of unified control over these multiple 
dependent elements. 


Elements of a PDMDM solution 


Whether it is a single-vendor solution, something home- 
grown, or a combination of third-party systems, the PXDPMDM 
solution has to be capable of handling three groups of activi- 
ties. Though configurations differ, most PDMDM solutions 
need to be able to do the following: 


/ Definition and development: As Figure 7-2 shows, the 
PDMDM solution must enable process analysis, data 
modeling, and process modeling. 


Y Data handling: The PDMDM solution needs to be able 
to acquire data, cleanse and de-dupe it, reconcile it with 
data in existing production databases, and manage hier- 
archies between data sets. 


Data distribution: Once cleansed and reconciled, the 
MDM system needs to distribute the data to operational 
and analytical systems that need it. 
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Figure 7-2: PDMDM solutions are multi-faceted and connected with many 
different areas of the corporate IT ecosystem. 


How PDMDM tools satisfy 
the C10’s requirements 


Your PDMDM solution needs to achieve its business goals 
while satisfying the CIO’s requirements. Consider a few exam- 
ples of PDMDM activity and how the right tool can make a big 
difference in the IT operations outcome. 


One thing you should know by now is that not all data is 
master data. And, not every master data object is as impor- 
tant as every other one, especially when you're trying to 
deploy optimal MDM projects that affect discrete business 
processes. MDM tools therefore need to handle both master 
data and transactional data and understand the relationships 
between the two types of data. 


Figure 7-3 shows an example of a PDMDM tool that can map 
relationships among master data objects and elements of busi- 
ness transactions. In the interest of not generating excessive 
work — or system modifications — the tool helps show the 
most concentrated levels of connection that need attention 
from an MDM perspective. This capability enables MDM work 
to proceed along an optimal path, focusing on what’s important 
to business processes without overtaxing other IT workloads. 
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Figure 7-3: Mapping master data to transactional data and process elements. 


On another front, think about how people actually get engaged 
with the PDMDM process. The CIO doesn’t want to start a 
system that will rope a ton of people into a lot of repetitive, 
time consuming work. For instance, Figure 7-4 shows the 
approval process required for new or updated master data. 

If you've ever worked with data, you'll know that databases 
frequently create messy situations where the ultimate deci- 
sion about what to do can only be made by a human being. 


Imagine if your MDM system kicked up two customers that 

it suspected were the same person, and therefore a candi- 
date for de-duplication. One is Gary Glass. The other is Gary 
F. Glass at a different address with a similar Social Security 
number. Is it the same person who simply moved from one 
place to another? Or, it is two totally different people with 
very similar names and social security numbers? It probably 
is just one person, given the probable inversion of two digits 
in the social security numbers. However, it’s best if someone 
can investigate and compare previous addresses for each man 
and figure out if it’s a simple mistake or if there are actually 
two men with the same name and almost identical socials. 


So far so good, but who exactly will do that investigation? 
Imagine that you work at a bank with 80,000,000 names on 
your customer list. This kind of query would arise constantly, 
so an efficient MDM system will allow for a well-governed 
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solution process. If the process of sorting out who is who in 
the database isn’t well structured, it will be inefficient and 
error prone. Figure 7-4 shows how specific users or groups 
can be automatically assigned to the approval process based 
on rules. APDMDM tool that can facilitate this kind of well- 
governed solution will be effective and in line with the kind of 
efficiency that the CIO wants to see in your PDMDM program. 
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Figure 7-4: The workflow required to approve new or updated master data. 


Additionally, being able to use fewer tools is usually a better 
option overall. For example, with the five elements in Figure 7-1, 
you may have just two or three tools to manage the whole situ- 
ation. The business model, process model, and data model may 
all be addressed by a single integrated development environment 
(IDE), which provides business analysts with business modeling 
tools that communicate process requirements to software devel- 
opers who create the application code that executes the process. 


SOA and MDM 


Service-oriented architecture (SOA), which has been preva- 
lent in the IT industry for about a decade, is a hidden enabler 
of PDMDM. SOA, an approach to application integration that 
uses XML standards to make virtually any piece of software 
able to communicate data or instructions to any other soft- 
ware, is the underlying glue that holds MDM together. 
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One way to understand the importance and necessity of SOA 
to MDM is to imagine what it would be like if SOA didn’t exist. 
Figure 7-5 captures the kind of complexity that you will see 

in most enterprises. This picture is from a real business, not 
invented for this book. Each block represents a data object or 
process component of a major system. When you look at this 
hairball, you have to wonder, “How can you connect any two 
parts of this mess and not break something?” Assume that the 
blocks in the figure represent four server operating systems, 
two internal network communication standards, and three 
types of databases. Ouch! 
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Figure 7-5: The relationship between master data and the complete set of 
processes and systems in an enterprise, showing the complex- 
ity and need for standards-based software to manage POMDM. 


You could, if you wanted, deploy custom-built connectors to 
realize the integrations necessary for PDMDM: For example, 
connecting the central MDM tool to the dependent systems. 
You will be perpetually fixing that set of connectors as you 
make changes to any part of the entire system. It simply won’t 
work, and believe us, it’s been tried. 
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To make PDMDM work in this kind of environment, you need 
to simplify and standardize how master data is collected and 
distributed by the central MDM tool. This is where SOA comes 
in. Using SOA, each application that needs to provide data to 
the MDM tool can become a “service” that delivers data ina 
standard manner using XML. XML is a free and open technol- 
ogy that has been adopted by all major technology compa- 
nies. In this way, the central MDM tools can collect data from 
a variety of applications in a standardized fashion regardless 
of the technology used to build the application. 


The benefits of SOA really shine when it comes to distributing 
good and clean master data back into operational systems 
and processes. Master data can be delivered using SOA ser- 
vices that can be easily found and invoked by applications 
and processes that need the master data. Moreover, all appli- 
cations that need a particular piece of master data can receive 
it using the exact same service. In this manner, you can dra- 
matically reduce the point-to-point connections between the 
central MDM tools and systems that consume master data. 
This approach also ensures that the same good and clean 
master data is used by all systems thus putting an end to 
proliferation of bad master data. 
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Chapter 8 


Ten Secrets to MDM 
Success 


In This Chapter 


Understanding problems and objectives 


Setting realistic responsibilities 


: following ten key success factors aren’t really secrets. 
They apply to any type of complex project. But, if MDM is 
your “baby,” the stakes will be high so you'll want to hit the 
right notes as you launch your PDMDM initiative. Take a deep 
breath. Your PDMDM initiative will be a huge success! These 
ten secrets will help you make it so. 


Understand the Business 
Problem 


Be sure you understand how MDM will help the business 
succeed. MDM projects can fail if they solve data issues that 
seem important to the IT team, but aren’t a priority for the 
business. Use techniques such as business process analysis 
and modeling to lay out how master data is used by business 
functions and what is the business impact of poor master data. 
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Set Realistic MDM Objectives 


Don’t try to solve all your organization’s problems at once ina 
“boil the ocean” approach to MDM. Set some specific and real- 
istic goals and then work to achieve those while demonstrat- 
ing measurable results. The best way to do this is to identify a 
small set of business processes that can significantly benefit 
from master data improvements. Start with them and expand 
scope to other processes as you demonstrate value. 


Keep Project Scope 
Clear and Tight 


Team members need to know the scope of the project and 
work to prevent scope creep. The best way to tackle addi- 
tional issues is with a second project to follow up on the suc- 
cess of your first project. 


Get Commitment Early 
from All Stakeholders 


MDM seems purely technical, so you need to build awareness 
that it’s about business. Communicate MDM’s business value 
to the management team. (Hint: Give them this book!) 


MDM Is Multidimensional! 


It is essential to invest in a structured MDM roadmap consid- 
ering business needs and external factors such as compliance, 
technological trends, and dependent parallel projects. 


Take a Process-Driven Approach 


Business processes should be the center of the MDM project. 
All business processes are dependent on information. The 
value from MDM is always in the way it improves how a pro- 
cess works. 
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Set Clear Responsibilities 


Business and IT are both responsible for master data. The 
MDM organization needs to assign roles from both parties with 
clear communication in between. Apply the RACI (responsible, 
accountable, consulted, informed) framework to your project 
to ensure that everyone knows their roles and responsibilities. 


Use Flexible Technology 


As the scope of MDM increases, you will have new data domains, 
new systems, new interfaces, and new applications to contend 
with. Be sure to select MDM technology that can accommodate 
different domains and MDM architectural styles within a single 
platform. This will allow you to expand MDM to new areas with- 
out having to acquire new tools, incurring additional costs, and 
learning new skills. It also will prevent a situation where multiple 
MDM tools end up creating new silos of information. 


Focus on Organizational 
Standards and Reusable Models 


MDM requires that the organization make decisions about 
the standard form of data. There is upfront cost to the orga- 
nization to agree on this standard because some groups may 
have to change what they’re doing to fit the standard. But the 
payoff for adopting the standard is a reusable data model that 
will reduce costs in the future. 


Don’t Forget Change 
Management 


Finally, never overlook the challenges that any change brings. 
People don’t like change, but if the process is managed well 
with clear expectations, your project is much more likely to 
succeed. Think about having a single person on your team 
whose chief role is to ensure that the change process is 
managed carefully. 
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Appendix 
Resources 


Web Resources 


™ Learn more about master data management including 
customer success stories and the latest news at 
www.softwareag.com/mdm. 


M Software AG’s corporate blog (blog.softwareag. 
com) contains news and updates on master data 
management, BPM, Process Intelligence, and SOA. Also 
check out Software AG’s twitter feed at twitter.com/ 
SoftwareAG. 


™ Forrester Research, Inc.’s MDM Blog (http://blogs. 
forrester.com/category/mdm) is a great source of 
information from independent research firm Forrester on 
the latest developments in the MDM market. 


M The Information Difference is an analyst firm focusing on 
master data management (MDM). Read their research at 
www. informationdifference.com. 


The MDM Institute provides numerous MDM resources 
including white papers and independent vendor reviews. 
The Institute also hosts the MDM & Data Governance 
Summit Series. Learn more at www. tcdii.com. 


Andrew White, Research VP at Gartner, maintains an active 
MDM blog. Read his postings at blogs.gartner.com/ 
andrew_white. 


Conferences 


M Gartner MDM Summit (www. gartner.com). Gartner 
hosts an annual summit focused on MDM. See thought 
leaders, customers, and vendors and find out about MDM 
directly from the experts. This event is good for both IT 
architects and business leaders. 
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M ProcessWorld (www. processworld.com). Software 
AG’s annual event provides attendees the opportunity to 
learn more about process improvement and the essential 
IT technologies for all organizations. 


MDM Market Research 


There are several excellent reports from independent market 
analysts. In particular, we recommend the following available 
from Forrester Research, Inc. (www. forrester. com): 


w Warning: Don’t Assume Your Business Processes Use 
Master Data (September 2009): www. forrester.com/ 
rb/Research/warning _dont_assume_business _ 
processes _ use _master/q/1id/46559/t/2 


M Trends 2011: It’s Time For The Business To Own Master 
Data Management Strategies (February 2011): www. 
forrester.com/rb/Research/trends_ 2011 time_ 
for_business_to_own/gq/1id/58399/t/2 


Avoid Process Data Headaches: Align Business 
Process And Data Governance Initiatives (November 
2010): www. forrester.com/rb/Research/avoid_ 
process _ data_headaches_align_business __ 
process/q/1id/57958/t/2 


Other Dummies Books 
from Software AG 


For an introduction to BPM and SOA, key technologies that 
support process-driven MDM, please check out Software AG’ s 
other For Dummies books at www. softwareag.com/dummies: 


BPM Basics For Dummies by Kiran Garimella, Michael 
Lees, and Bruce Williams. 


Y SOA Adoption For Dummies by Miko Matsumura, Bjoern 
Brauel, and Jignesh Shah. 


Y Process Intelligence For Dummies by Tobias Blickle, Helge 
Hess, Joerg Klueckmann, Mike Lees, and Bruce Williams. 
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Improve Master Data Where It 
Really Matters 


Score measurable improvements with 
process-driven MDM. 


Everyone loves MDM when quality data leads to clear business 
benefits. Our unique process-driven approach helps you under- 
stand how poor data is hurting your business. And our MDM 
technology helps you fix the bad data—and keep it fixed. For 
more information, please visit www.softwareag.com/MDM 
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Get yours today at 
www.SoftwareAG.com/dummies 


These materials are the copyright of John Wiley & Sons, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 





Use the three essential 
pillars of process-driven 
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